an analysis of voice over internet protocol in wireless ... · voice over internet protocol in...
TRANSCRIPT
An analysis of voice over Internet Protocol in
wireless mesh networks
Mohammad Tariq Meeran
Thesis presented in fulfillment
of the requirements for the degree of
Master of Science
at the University of the Western Cape
Supervisor: Dr. William D. Tucker
December 2011
Abstract
This thesis presents an analysis of the impact of node mobility on the quality of service for
voice over Internet Protocol in wireless mesh networks. Voice traffic was simulated on such
a mesh network to analyze the following performance metrics: delay, jitter, packet loss and
throughput. Wireless mesh networks present interesting characteristics such as multi-hop
routing, node mobility, and variable coverage that can impact on quality of service. A
reasonable deployment scenario for a small organizational network, for either urban or rural
deployment, is considered with three wireless mesh network scenarios, each with 26 mesh
nodes. In the first scenario, all mesh nodes are stationary. In the second scenario, 10 nodes
are mobile and 16 nodes are stationary. Finally, in the third scenario, all mesh nodes are
mobile. The mesh nodes are simulated to move at a walking speed of 1.3m per second. The
results show that node mobility can increase packet loss, delay, and jitter. However, the
results also show that wireless mesh networks can provide acceptable quality of service,
providing that there is little or no background traffic generated by other applications. In
particular, the results demonstrate that jitter across all scenarios remains within human-
acceptable tolerances. It is therefore recommended that voice over Internet Protocol
implementations on wireless mesh networks with background traffic be supported by
quality of service standards; otherwise they can lead to service delivery failures. On the
other hand, voice-only mesh networks, even with mobile nodes, offer an attractive
alternative voice over Internet Protocol platform.
iii
Categories and Subject Descriptors
C.2.1 [Computer-Communication Networks]: Network Architecture and Design -
Wireless Communication; D.2.8 [Metrics]: Performance Measures; C.2.2 [Network
Protocols]: Routing Protocols/Wireless Mesh Network
v
Declaration
I, MOHAMMAD TARIQ MEERAN, declare that this thesis "An analysis of voice over Internet
Protocol in wireless mesh networks" is my own work, that it has not been submitted before
for any degree or assessment at any other university, and that all the sources I have used or
quoted have been indicated and acknowledged by means of complete references.
Signature: . . . . . . . . . . . . . . . . . . . . . . . . Date: 20 December 2011
Mohammad Tariq Meeran
vii
Acknowledgements
This thesis is a compilation of the efforts of many people who helped and guided me
through the years. I would first like to thank my supervisor, Dr. William Tucker for
supporting and encouraging me during my Masters study. Without his help, this work
would not have been possible. At this time I would like to extend a very special thanks to
Prof. I. M. Venter, Prof. Reg Dodds, Verna Connan, Fatima Jacobs and Leonie Dyamond
without whose help, I would certainly not be where I am today.
I would also like to thank USAID for their unwavering financial assistance without
which our efforts would have been impossible. I appreciate the help of Dr. Jan Plane from
the University of Maryland who assisted me with my academic writing and English, and
who also instructed me in research methods. Also, I would like to thank all the members of
the Computer Science Department of the University of the Western Cape, Prof. Babury,
Deputy Minister of Higher Education of Afghanistan, Dr. Ashraf Ghani, the previous
Chancellor of Kabul University, Prof. Hamidullah Amin the current Chancellor of the
Kabul University and Prof. Mohammad Homayoun Naseri, the Dean of the Computer
Science Faculty, for their interest and support for organizing this program and facilitating
our trip to South Africa.
ix
Contents Abstract ................................................................................................................................... i
Categories and Subject Descriptors ....................................................................................iii
Declaration ............................................................................................................................. v
Acknowledgements .............................................................................................................. vii
Contents ................................................................................................................................. ix
List of figures ........................................................................................................................ xi
List of tables ........................................................................................................................xiii
List of acronyms .................................................................................................................. xv
1 Introduction ...................................................................................................................... 1
1.1 Background ..................................................................................................................... 1
1.2 Research question and overall approach ......................................................................... 5
1.3 Thesis outline .................................................................................................................. 6
2 Related work ..................................................................................................................... 7
2.1 Mesh networks ................................................................................................................ 7
2.2 Wireless mesh networks .................................................................................................. 8
2.3 VoIP QoS ...................................................................................................................... 13
2.4 Wireless mesh and VoIP QoS ....................................................................................... 15
2.5 Summary ....................................................................................................................... 19
3 Methods ........................................................................................................................... 21
3.1 Research approach ........................................................................................................ 21
3.2 Experimental design ...................................................................................................... 23
3.2.1 Simulation environment ............................................................................................. 23
3.2.2 Mesh topology ............................................................................................................ 26
3.2.3 Mesh routing protocol ................................................................................................ 26
3.2.4 Traffic profiles ............................................................................................................ 27
3.3 Scenarios ....................................................................................................................... 31
3.3.1 No mobility scenario .................................................................................................. 32
3.3.2 Limited mobility scenario ........................................................................................... 36
3.3.3 Full mobility scenario ................................................................................................. 40
3.4 Data collection ............................................................................................................... 45
3.5 Summary ....................................................................................................................... 46
4 Analysis of results .......................................................................................................... 48
4.1 No mobility scenario results .......................................................................................... 48
4.2 Limited mobility scenario analysis ............................................................................... 51
4.3 Full mobility scenario analysis...................................................................................... 55
4.4 Comparative analysis .................................................................................................... 58
4.5 Summary ....................................................................................................................... 62
5 Conclusion and future work ......................................................................................... 63
5.1 Research conclusion ...................................................................................................... 63
5.2 Recommendations ......................................................................................................... 64
5.3 Limitations .................................................................................................................... 65
5.4 Future work ................................................................................................................... 65
Bibliography ......................................................................................................................... 67
Appendix A Unpublished draft paper ............................................................................... 71
xi
List of figures
Figure 1-1 Wireless mesh network example ........................................................................... 2
Figure 1-2 Packet loss ............................................................................................................. 4
Figure 1-3 Real-time application video example .................................................................... 5
Figure 3-1 Overview of research approach ........................................................................... 22
Figure 3-2 Selecting NCTUns kernel .................................................................................... 24
Figure 3-3 NCTUns dispatcher ............................................................................................. 25
Figure 3-4 NCTUns coordinator ........................................................................................... 25
Figure 3-5 NCTUns client ..................................................................................................... 25
Figure 3-6 NCTUns 6.0 workspace ....................................................................................... 25
Figure 3-7 Wi-Fi mesh topology for 26 nodes ...................................................................... 26
Figure 3-8Meshnode‟sphysicallayerandchannelmodelparameters ................................ 26
Figure 3-9. Speaker 1 STG configuration script ................................................................... 30
Figure 3-10. Speaker 2 STG configuration script ................................................................. 30
Figure 3-11 Summary of different scenarios ......................................................................... 31
Figure 3-12 No mobility, VoIP only profile .......................................................................... 33
Figure 3-13 VoIP and non-VoIP profile simulation .............................................................. 35
Figure 3-14 Limited mobility scenario VoIP only profile ..................................................... 38
Figure 3-15 Full mobility scenario ........................................................................................ 42
Figure 3-16 RTG usage options ............................................................................................ 45
Figure 3-17 RTG log file content .......................................................................................... 45
Figure 3-18 Throughput logging in NCTUns ........................................................................ 46
Figure 4-1 No mobility scenario: Delay analysis .................................................................. 49
Figure 4-2 No mobility scenario: Jitter analysis .................................................................... 50
Figure 4-3 No mobility scenario: Packet loss analysis .......................................................... 50
Figure 4-4 No mobility scenario: Throughput analysis ......................................................... 51
Figure 4-5 Limited mobility scenario: Delay analysis .......................................................... 52
Figure 4-6 Limited mobility scenario: Jitter analysis ............................................................ 53
Figure 4-7 Limited mobility scenario: Packet loss analysis .................................................. 54
Figure 4-8 Limited mobility scenario: Throughput analysis ................................................. 54
Figure 4-9 Full mobility scenario: Delay analysis ................................................................ 56
Figure 4-10 Full mobility scenario: Jitter analysis ................................................................ 56
Figure 4-11 Full mobility scenario: Packet loss analysis ...................................................... 57
Figure 4-12 Full mobility scenario: Throughput analysis ..................................................... 58
Figure 4-13 Delay analysis of all scenarios and traffic profiles ............................................ 58
Figure 4-14 Jitter analysis of all scenarios and traffic profiles ............................................. 59
Figure 4-15 Packet loss % of all scenarios and traffic profiles ............................................. 60
Figure 4-16 Throughput analysis of all scenarios and traffic profiles ................................... 60
Figure 5-1 Number of nodes exceeding VoIP QoS factor limits ......................................... 64
xiii
List of tables
Table 1 VoIP random pairing ................................................................................................ 27
Table 2 VoIP profile of human conversation ........................................................................ 29
Table3Meshnodes‟distancesinstationarypositioninmetres ........................................... 32
Table 4 Nodes VoIP Communication. (starting time in seconds) ......................................... 33
Table5Limitedmobilityscenarionodes‟movementinformation ....................................... 37
Table 6 Full mobility scenario's mesh node movement position information ....................... 41
Table7Limitedmobilitynodes‟communicationpeers ........................................................ 53
Table 8 Summary of all VoIP factors for all scenarios and traffic profiles .......................... 61
Table 9 Number of nodes exceeding the acceptable VoIP QoS limits .................................. 62
xv
List of acronyms
BATMAN Better Approach to Mobile Ad-hoc Networking
DSDV Destination-Sequenced Distance Vector routing protocol
DSR Dynamic Source Routing
GodRP God Routing Protocol
IEEE Institute of Electrical and Electronic Engineering
IPD Inter Packet Delay
LAN Local Area Network
MAC Media Access Control
MANET Mobile Ad-hoc Network
NCTUns National Chiao Tung University Network Simulator
NS2 Network Simulator 2
OLSR Optimized Link State Routing Protocol
QoS Quality of Service
RTCP Receive Transmission Control Protocol
RTG Receive Traffic Grapher
RTP Real-time Transport Protocol
RTT Round Trip Time
STA Station
STCP Send Transmission Control Protocol
STG Send Traffic Grapher
TCP Transmission Control Protocol
UDP User Datagram Protocol
VoIP Voice over Internet Protocol
Wi-Fi Wireless Fidelity
WMN Wireless Mesh Network
WSN Wireless Sensor Network
1 Introduction
This thesis presents an analysis of voice over Internet Protocol (VoIP) applications‟ quality
of service (QoS) issues on wireless mesh networks (WMNs). The unique characteristics of
WMNs can cause VoIP applications to have QoS problems. Studies show that WMNs‟
unique characteristics are manifested by combining the features of mobile ad-hoc networks
(MANETs), wireless sensor networks (WSNs) and cellular technologies [25] [51], but these
features cause QoS challenges for VoIP implementations. VoIP applications also have their
own characteristics, which include sensitivity to delay, jitter, packet loss and use of small
packets. Each one of these characteristics is a QoS factor for any given VoIPapplication‟s
success. For example, if the delay, jitter and packet loss rate are not matching physical
performance thresholds or human-acceptable tolerances, then VoIP QoS will be affected
negatively. This can result in user dissatisfaction and complaints about the quality of service
level. The research described in this thesis focuses on studying VoIP applications‟ QoS by
exploring how this type of traffic is affected by different WMN scenarios, particularly when
some or all nodes are mobile. Many WMN scenarios exist today. These include mesh
networks with no mobility, mesh networks with limited node mobility and mesh networks
with full node mobility. The mobility speed can also vary in the latter two scenarios, based
on the type of equipment and the purpose for which it is being used. A mesh node can have
a slow mobility, like pedestrian users, medium speed, like a bicycle or yacht, and faster
speeds like motorized vehicles, e.g. motorcycles or trains.
1.1 Background
A WMN is a form of wireless LAN (Local Area Network) which is considered to be a type
of ad-hoc network, while sharing characteristics of mobile ad-hoc networks, WSNs and
cellular networks. WMNs can be formed by a mix of wireless clients, wireless access points
and wireless routers (gateways). The wireless clients/access points/routers can be stationary
or mobile and can be implemented alone or mixed with other devices to form WMNs. They
provide multiple and redundant paths (routes) for each other. WMNs are multi-hop, self-
healing, self-organizing networks with dynamic topologies, using purpose-built routing
protocols. WMNs are widely deployed in areas where building wired infrastructure requires
a considerable amount of time and money like the emergency relief hotspots, rural areas,
battlefields, education etc., in order to support various applications and services, like web
2
A
B
G
D
F
E
C
browsing, e-mail, file transfer (non real-time), voice and video (real-time). Non real-time
services are not greatly affected by delay and jitter that are produced as a result of high
loads, low bandwidth, longer distances and mobility, but real-time traffic is affected, since it
requires lower latency, lower jitter, affordable packet loss rate and better throughput.
WMNs provide better coverage, throughput, redundancy and fault tolerance, but there are
some QoS problems, due to WMNs' dynamic and complex topologies, multi-hop nature,
node mobility, medium usage routing/relaying capabilities, bandwidth allocation and traffic
prioritization for real-time traffic, which require affordable delay, jitter and packet loss.
The IEEE (Institute of Electrical and Electronic Engineering) 802.11‟s standard for
WMNs considers the mesh nodes as part of the network infrastructure, whether stationary
or mobile [51]. In this research WMNs‟ formations will only be by wireless mesh clients.
This research does not consider wireless access points and wireless routers to be part of the
mesh design and topologies. Studies show that WMNs introduce more delay, jitter and
packet loss and they may be causing problems for the VoIP applications [40]. Besides,
WMNs do not share a single point of failure. If one node fails for any reason, another node
is selected instead. For example, Figure 1-1 shows a wireless mesh node where node A can
reach node D, using any of the following available routes:
1.B→C 2.B→C→G 3.B→C→G→E 4.B→C→G→F→E
5. G 6.G→C 7.G→B→C 8.G→E
9.G→F→E 10.F→G 11.F→G→C 12.F→G→B→C
13.F→E 14.F→E→G 15.F→E→G→C 16.F→E→G→B→C
Figure 1-1 Wireless mesh network example
3
As the above figure shows, there are many routes that can be used by each mesh node.
Normal wireless networks and routing protocols do not allow mesh nodes to discover and
use these many routes. Therefore WMNs use specific routing protocols to make use of these
many routes. The wireless mesh nodes must be equipped with wireless mesh protocols and
be aware of the topology. They also need to support wireless mesh routing protocols in
order to build mesh routing tables, perform load balancing and be able to discover
redundant routes and use them if one route or a next hop is not available.
QoS has several meanings. ITU-T defines QoS as "the collective effect of service
performance which determine the degree of satisfaction of a user of the service."1 One
definition relates QoS to the mechanism or the technology, which has the power to prioritize
data flows based on the application requirements and user satisfaction. QoS is application
dependent andrequiresdifferentlevelstosatisfyusers‟needs.In other words, QoS refers to
control mechanisms that can provide different priority to different users or data flows, or
guarantee a certain level of performance to a data flow in accordance with requests from the
application program. Other sources offer the following as a definition: „„QoSrepresentsthe
set of those quantitative and qualitative characteristics of a distributed multimedia system
necessary to achieve the required functionality of an application‟‟[9].
The concepts of delay and latency are similar concepts in the field of
telecommunication. In this research, the term delay is used instead of latency. Delay is
defined as the measurement of time between the moment that something is initiated and the
moment that its effects begin. In communications it can be measured either as a one-way
delay or round-trip-delay. One-way delay is the time taken from when the source sends a
packet, until the destination receives it. Round-trip-delay is the time taken when the source
sends the packets and the destination acknowledges the reception back to the source. Delay
is usually a problem in packet switched networks (connectionless networks). It is a general
problem in the telecommunication field. Usually satellite links introduce more delay than
wired links. This typically affects real-time traffic, like voice and video in slow speed and
congested network connections [49]. Studies suggest that the acceptable delay for voice
over Internet Protocol (IP) traffic is 100-150ms [24] [27]. Other studies suggest that
acceptable delay for voice over IP is 200ms [49]. The most appropriate way to decrease
delay, is reserving bandwidth among the routing and switching nodes that may cause delay
between the sender and the receiver, or prioritizing the traffic by QoS methods.
1 ITU-T Rec. G.1000 (11/2001) Communications Quality of Service: A framework and approach
4
Jitter in the field of telecommunication is used to describe the time difference and
intervals between the pulses that are transmitted successfully. It can also be quantified by all
time varying signals between source and destination. In packet switched networks, jitter is
usually considered a problem. Packet switched networks are designed in such a way that
packets can be routed using different paths in the network. Therefore, packets may arrive at
different time intervals, due to queuing delay variation at each node [27], which causes
problems. Studies show that an acceptable jitter rate between the source and destination
communication point is less than 100 ms [38] [48]. If it is more than 100ms, it should be
reduced. Usually to solve the problem with jitter, a „‟jitter buffer‟‟ is used. It is a small
buffer which receives the packets and then transmits them to the receiver with a small delay.
If a packet is not in the buffer, it means that the packet is lost or has not arrived, and if it
won‟t harm the communication, it will not be taken into account. If the size of the jitter
buffer is increased, the delay time will be increased, and less packet loss might occur. If the
jitter buffer size is decreased, it means less delay, but more packet loss.
Packet loss is defined as the loss of packets (portion of data) during the
communication between the stations over a computer network, as shown in Figure 1-2.
There are several factors that can cause packet loss. They include degradation of signal,
congestions on the network links, low signal quality, corrupted packets, faulty hardware,
etc. Packet losses of more than the tolerable rate can cause problems of session
disconnections between the two communicating stations. Real-time traffic, like voice and
video can be greatly affected by a high packet loss rate. Acceptable packet loss rate for
VoIP is considered to be less than 5% of a whole conversation [3].
Figure 1-2 Packet loss
Throughput is the average amount of data that is successfully delivered over a
communication link. The maximum throughput is less than or equal to the amount of digital
bandwidth. It is measured by bits/bytes per seconds [55]. Throughput for VoIP traffic varies
based on the type of codec being used and the amount of compression applied. A common
G.729A codec, with 8 bits compression, uses 32 kbps throughput [50], but if the size of the
VoIP payload increases or decreases, the amount of throughput will change accordingly.
5
Real-time traffic, as shown in Figure 1-3, refers to data flows within the network
that have to be transmitted and received almost at the moment that they are generated. They
are usually associated with deadlines after which the data will be considered unusable. In
this research, the term real-time traffic refers to the voice and video traffic.
Good Quality Poor Quality
Figure 1-3 Real-time application video example
VoIP is the usage of data networks to transport voice over the Internet or internal
networks. VoIP mainly provides low cost calls compared to the phone system, using a
circuit switched technology [14]. VoIP is supported by several protocols and it has its own
set of characteristics which are not common in other types of applications. These include the
use of Real-time Transport Protocol (RTP), User Datagram Protocol (UDP), IP, small
packets and big packet headers. VoIP can use several types of codec to provide poor,
average or high QoS, depending on the type of connection and technology available. VoIP
is considered to be sensitive to delay, jitter and packet loss.
1.2 Research question and overall approach
The usage of VoIP applications is becoming more popular daily. VoIP implementation over
fiber, copper and wireless networks are becoming more common, but studies show the VoIP
applications are having QoS issues in WMNs. Therefore, VoIP implementations in WMNs
require more research in order to discover the reason that lead to QoS issues and affect the
VoIP QoS factors. This research mainly focuses on WMN scenarios and simulating
mesh nodes in stationary and mobile modes. The aim is to discover how and which VoIP
QoS factors are affected. The focus of this thesis is to answer the following research
question, which will be discussed in detail in Chapter 3: How is VoIP QoS affected by
WMNs' node mobility?
6
In order to conduct this research, the NCTUns 6.0 (National Chiao Tung University
Network Simulator) was chosen. Three wireless mesh scenarios were designed. The no
mobility scenario was designed to simulate mesh nodes in stationary position, the limited
mobility scenario was designed to simulate 10 mobile nodes and 16 stationary nodes and the
full mobility scenario was designed to simulate all mesh nodes moving. Node movement
was configured with the walking speed of 1.3m/sec. In each scenario, two traffic profiles
were tested. Traffic generation tools were used to generate traffic. Profile 1 was scripted to
generate only VoIP traffic; profile 2 was scripted to generate VoIP and non-VoIP traffic.
1.3 Thesis outline
In order to present how VoIP quality is affected by WMNs' node mobility, this thesis is
structured into 5 chapters. The introductory chapter discussed the main focus of the thesis,
introduced some of the applicable terms and summarized the research approach.
Chapter 2 presents the related work on the WMNs and VoIP QoS domains. Several
types of mesh networks and WMNs are introduced. VoIP QoS and its characteristics and
factors follow a discussion of WMN characteristics, formations and types. Finally, the
implementation of VoIP applications on WMNs is presented.
Chapter 3 presents the methods, research question, methodological approach,
simulation environment, WMN topologies, mesh routing protocols, scenarios and data
collection method. It also focuses on VoIP and non-VoIP traffic profiles, simulation
software usage, traffic generation tools and commands for simulating WMNs and VoIP
traffic.
Chapter 4 presents the analysis of results, with the main focus on how VoIP traffic is
affected by mesh node mobility. It analyzes each QoS factor, like delay, jitter, packet loss
and throughput separately, considering the WMN scenarios and traffic profiles. Finally, all
the scenarios and traffic profiles are compared and the analysis is presented.
Chapter 5 summarizes the research and discusses the research limitations, along with
some recommendations and future work.
Appendix A presents an unpublished 5-page draft of a paper in SATNAC format.
This paper has a co-author, as mentioned in the paper heading, but this thesis is the sole
work of the thesis author.
7
2 Related work
Many researchers have studied WMNs and its effect on VoIP applications. The studies
show that WMNs and VoIP applications have some interesting and unique characteristics
compared to other types of networks and applications. The standards developed to address
the QoS issues in wired and wireless networks do not directly apply to WMNs, because
these networks operate differently than other types of networks. Since WMNs are
considered a newly-emerged types of wireless networks, it is still an open and active
research field for finding ways and solutions to solve the associated problems and provide
better service for end users. This chapter is structured to discuss the related work in the
WMN and VoIP QoS domain. In Section 2.1 mesh network types are presented in general.
Section 2.2 presents WMNs usage types, characteristics and formation. Section 2.3 presents
VoIP QoS special characteristics and VoIP QoS critical metrics. Section 2.4 discusses the
WMNs and VoIP implementations, with more focus on researchers‟ efforts and findings in
problems associated with VoIP application in WMNs. This section also discusses the
measuring VoIP QoS factors in WMNs. Finally, Section 2.5 presents a summary of related
work of the research community.
2.1 Mesh networks
Mesh networks are usually formed to eliminate the single point of failures, to provide
redundant paths, to be able to self-heal in case of small and big scale outages and to build
reliable networks. Many types of network technologies can form mesh networks. Today the
use of fiber optic, copper and WMNs are common. Fiber optic mesh networks are built to
form intra-building, intra-campus, intra-city, intra-country, regional and intercontinental
links. These links form the backbone of the modern networks, as well as the Internet, and
are usually used to connect core switches and routers. Copper mesh networks are commonly
used in intra building LANs to connect switches and routers. WMNs can be used to connect
mobile users, intra building LANs, intra campus LANs and even intra city and country
networks. WMNs can connect to user equipment, like mobile phones, laptops, PDAs,
desktops and infrastructural equipment, like access points and wireless routers. By
considering the mesh network formation and its connectivity to different types of devices, it
is clear that only the WMNs are addressing the user level and infrastructural mesh
connectivity, while the wired mesh networks are usually connecting infrastructural devices.
8
Today most of the user level devices are equipped with wireless technology, like Bluetooth
[6-7] and Wi-Fi (Wireless Fidelity). For the infrastructural level the use of Wi-Max
(Worldwide Interoperability for Microwave Access) [56] and Wi-Fi technologies are
usually common, depending on the type, terrain, bandwidth requirements and interference
considerations.
2.2 Wireless mesh networks
The study of WMNs is an active research field. WMNs are considered self-healing, self-
optimizing and fault tolerant networks [42] [34] [23]. A WMN is a unique type of network,
since it combines the characteristics of MANETs, WSNs and cellular technologies.
Generally WMNs are considered to be a type of MANET. The similarities between WMNs
and MANETs lie in the multi-hop nature and node mobility, but the differences include the
following [26] [51]: the WMN nodes use gateways to reach the internet, wired LAN or
other WMNs. Traffic flow in WMNs is usually between the client and the internet through
the gateways, while in MANETs, the node can be the source and destination of the flow,
although there are some cases of node to node communication in WMNs that are the same
as MANETs [2]. WMN nodes can be stationary or mobile, but MANETs‟ nodes are usually
expected to be mobile. WMNs‟ infrastructure and architecture are considered to be fixed or
have very low mobility and are formed by access points, routers and gateways. WMNs do
not consider mobile nodes as part of the WMN infrastructure, but MANETs‟ infrastructure
is formed by mobile nodes, which are considered to be part of the WMN infrastructure.
Backbone devices of WMNs are considered to be non-energy constrained devices, while
MANETs‟ nodes are considered to be backbone and energy constrained devices.
WMNs make use of available natural resources, like air, to transmit the information
in the form of modulated radio waves, without the use of wires, from one location to
another. This makes it affordable for the least developed and developing countries [8]. The
success of WMNs is that they allow computers to reach each other in public and rural areas.
Directional-point-to-point antennas are also used to build backbone links. These make it
possible to connect longer distances. Furthermore, vendors are very interested in producing
equipment for this technology [44]. There is also wide spread industry support for wireless
networks. Companies like Nokia, Microsoft, Motorola and Intel are actively working to
support WMNs [51]. Reduction in wireless mesh equipment prices, as well as compatibility
among them, is increasing, but there is lack of regulatory overhead on unlicensed
9
frequencies. Major drawbacks for WMN are short signal range, interference (because of
using unlicensed frequencies), the way the medium is used and that bandwidth is shared
among the nodes. Wireless networks take advantage of natural resources and can therefore
be deployed faster than wired networks. Low cost systems, based on wireless technologies,
have been installed in rural villages, in South East Asia, resulting in a two times lower cost
than that of wired solutions [21].
WMNs are implemented to address different types of user needs and provide various
services. A study by [45] shows that hundreds of cities are planning and implementing
WMNs for public Internet access, safety and businesses. Vendors must also focus on
providing QoS, address issues related to mobility and support public and business
applications. The author also states that some wireless mesh products are focusing on layer
two, for providing better QoS, while some vendors focus on layer three's instant routing
products, to provide QoS and achieve zero downtime. Today people are expecting to be
connected anytime and anywhere with their mobile phones, PDAs, laptops and other hand-
held devices. This is a great opportunity for businesses to introduce more wireless enabled
devices in the areas of health, education and entertainment [42]. Development in the multi-
media computing environment has resulted in producing networking devices which have the
capability to carry different types of traffic. The types of traffic include text, images, audio
and video. Carrying audio and video across wireless links, which is referred to as real-time
traffic, requires QoS for prioritization [41]. For this reason the IEEE 802.11e MAC (Media
Access Control) protocol was proposed to provide QoS on the MAC layer. In the MAC
layer, it uses the CSMA/CA (Carrier Sense Multiple Access /Collision Avoidance)
mechanism to avoid collision and to share the medium, based on single hop transmission.
Research done by [46] and [39], also confirms that since WMNs are characterized as multi-
hop transmission, the IEEE 802.11e which deals with QoS, does not fit the requirements of
WMNs.
WMNs are defined by the IEEE 802.11‟s standard. This standard is based on
802.11a, 802.11b, 802.11g and 802.11n which carry the actual traffic. This standard
requires Hybrid Wireless Mesh Protocol (HWMP) to be supported by default on the mesh
nodes, but it also allows the use of other link state routing protocols, like OLSR (Optimized
Link State Routing) and BATMAN (Better approach to mobile ad-hoc networking), and
even static routes are supported. In this standard, the mesh nodes are called Mesh Stations
(Mesh STAs). Mesh STAs are allowed to build links with their neighboring Mesh STAs or
access points. Mesh STAs are considered to be power-constrained devices, able to relay
10
traffic to other destined nodes. This standard and its amendments are expected to be applied
to software only and no changes are required on the existing 802.11 chipsets and hardware.
This standard is still in its preliminary stages, but there are some products, like the One
Laptop per Child (OLPC) project, that have implemented the 802.11s draft [43].
Today wireless networks are extended by another alternative: multi-hop WMNs.
Mesh networks are formed by stationary/mobile wireless clients or routers that can be from
different vendors. Mesh network deployment is easy and requires less maintenance and
administration and once more users join the network, more wireless routers can be added to
result in an extended coverage area. The performance of the network could be affected by
delay, jitter, packet loss, the number of hops, number of channels, clients, routers, antenna-
positioning, mobility, throughput and application requirements [34].
Wireless networks can be divided into four main categories. They can be single-
channel single-hop, multiple-channel single-hop, single-channel multiple-hop or multiple-
channel multiple-hop [32]. From these four categories, only the latter two, which are single-
channel multiple-hop and multiple-channel multiple-hop, are considered as the basis for the
WMNs formation.
Single-channel single-hop wireless networks are formed by one channel and one
hop. In this type of network, as the number of users increases, the overall throughput
decreases. Research has been conducted by [47] in 802.11b standard, using one access
point, nine laptops and five PCs. Traffic generation was done through customized software
that generated UDP packets. This research shows that as the number of nodes increases, the
overall throughput decreases. This research also shows that network performance is more
dependent on the wireless card implementation than the nodes‟ processing power and
capacity.
Multiple-channel single-hop wireless networks are formed by nodes
communicating with each other directly, establishing a peer-to-peer connection among the
nodes. Each node sends the data independently. Interference and collision among the
channels are not possible, since each device is using a separate data channel. A study by [5]
suggests that energy-efficient routing protocols can result in uniform energy usage by the
nodes. These types of networks perform well, but building such a network is very
expensive, since it requires non-overlapping data channels for each node‟s communication.
The process will therefore be costly for the end users, despite the fact that it results in a
single-hop approach which does not provide redundancy and multiple paths.
11
Single-channel multiple-hop is a single-channel multiple-hop wireless network. It
is also called an ad-hoc or mesh network [22]. In this type of wireless network, the mesh
nodes use one shared channel across the network. The medium bandwidth is divided among
the nodes using the same channel. Bandwidth allocation to each node is lower compared to
multiple-channel multiple-hop networks, but this type of network is easier and cheaper to
build. If bandwidth-hungry applications are properly managed, this type of network
performs well, but if the network is expanded greatly and the number of nodes increases,
then the mesh node performance degrades and all nodes experience lower bandwidths,
packet loss, higher latency and jitter.
Multiple-channel multiple-hop wireless networks are also called ad-hoc or mesh
networks. They are good for capacity enhancement and can use multiple channels on multi-
hop mesh networks, instead of using a single chunk of 20 MHz frequency that is provided
by the LAN standards. By using multiple channels, the sending stations can make use of the
two channels that are available and can send the data. On the receiving end, the station can
receive and send, using multiple channels. Such a system can provide more capacity than
the single channel provided that appropriate protocols are used [4] [11]. Research [44]
shows that a solution to achieve higher bandwidth, less delay and jitter when using multiple
channels in a multi-hop network, is to use separate channels for clients and for backhaul
ingress and egress traffic, in order to achieve full duplex bandwidth. Another experimental
research project by [32], which studied the performance of 802.11b wireless mesh multi-
hop backbone networks, regarding multiple channel usage, shows that using non-
overlapping channels on multiple radios, gives a better performance than the single-radio
implementation. The round trip time (RTT) was lower in two-cards multiple channel than
two-cards one channel and one-card one channel. The experiment also shows that for
WMNs non-overlapping channels can provide better throughput, which is the total amount
of data that is successfully transmitted to the user.
According to the above research, using multiple channels in multi-hop mesh
networks, provide better bandwidth and better round trip time than single channel multi-hop
networks. Unfortunately building a mesh network with multiple channels is expensive,
because a separate radio is needed for each channel that the device is using. For example, if
5 wireless routers and 10 wireless clients are used in a WMN, and multiple non-overlapping
channels of 1, 6 and 11 are used, three radio transceivers are required on each device:(5x3)
+(10x3)=15+30=45. As a result it becomes very expensive to build such a mesh network,
unless new radio technology will allow using multiple radio frequencies in a single radio.
12
Studies also show that multi-channel multi-hop networks are not good choices for VoIP
applications that use a round robin schedule for switching between multiple channels,
because the time needed to switch between channels, does not meet the VoIP requirements
[10].
A better, more practical and cheaper approach to build WMNs, is to use a single-
channel and multi-hop. This requires a single radio frequency for all devices participating in
the mesh network. If QoS mechanism is properly implemented, the problem with delay,
jitter, packet loss and better bandwidth can be addressed effectively. Since WMNs have a
dynamic formation with multiple paths for the packets, and links are coming up and going
down frequently and changing their positions by being mobile, the convergence and
synchronization of the routing table requires a routing protocol that can adjust itself to the
network topology and prevent routing loops in mesh networks. Mesh routing protocols‟
choice and characteristics can affect the QoS [26]. There are several important factors for
choosing a mesh routing protocol, like the size of network, the nodes‟ mobility and type of
traffic. Mesh routing protocols are usually classified as proactive, reactive or hybrid.
Mesh networks require resource management in order to provide better QoS. There
are three areas that can be addressed by mesh resource management processes. Firstly,
network configuration and deployment, secondly, routing, and lastly mobility management
and admission control [51]. There are many mesh routing protocols, but some of them are
more commonly used. These protocols are: BATMAN (Better approach to mobile ad-hoc
networking), DSDV (Highly Dynamic Destination-Sequenced Distance Vector routing
protocol), HSR (Hierarchical State Routing protocol), ZRP (Zone Routing Protocol), IARP
(Intrazone Routing Protocol/pro-active part of the ZRP), WAR (Witness Aided Routing),
OLSR (Optimized Link State Routing Protocol), DSR (Dynamic Source Routing), TORA
(Temporally Ordered Routing Algorithm), CGSR (Clusterhead-Gateway Switch Routing),
GeoCast (Geographic Addressing and Routing), DREAM (Distance Routing Effect
Algorithm for Mobility), LAR (Location-Aided Routing), AODV (Ad-Hoc On Demand
Distance Vector Routing), FSR (Fisheye State Routing), TBRPF (Topology Broadcast
Based on Reverse Path Forwarding), LANMAR (Landmark Ad-Hoc Routing Protocol),
GPSR (Greedy Perimeter Stateless Routing) [51]. Another routing protocol, GoDRP, is also
used by simulation software, like ns2 (Network Simulator 2) and NCTUns, to calculate the
routes based on nodes' position and signal range, without any routing protocol overhead.
This type of routing protocol is used to benchmark the simulations to the best way a routing
protocol can theoretically perform [15] [52].
13
2.3 VoIP QoS
There are many services provided by computer networks. One of the most used services is
VoIP. Using a computer network for VoIP communication is relatively cheaper, since it
uses existing infrastructure and the users can use the service from anywhere, using various
devices like VoIP phones, PDAs (Personal Digital Assistants), laptops, desktops, smart
mobile phones, etc. VoIP applications have unique characteristics, because of its real-time
mode of communication, small packets, sensitivity to delay, jitter and packet loss [40] [25].
Although VoIP applications have been widely used for more than 20 years, there is still a
lack of QoS for VoIP applications in the new emerging networks. VoIP applications are
unique in that they exchange many small packets which are made of big packet headers and
small VoIP payloads, but little effort has been made to address and investigate these
problems on wireless multi-hop networks [28] [29].
VoIP requires call admission methods to admit the call. A study by [3] addresses
two questions in WMNs to support VoIP. Firstly, in order to maintain QoS, the call
admission has to be studied. This can be done by measurement-based models that can model
the available capacity and can help in call admission decisions. The second question is to
find a feasible route, considering the ratio of interference and carrier sensing ranges. This
evaluates the path to see if it is feasible for the route selection processes. This study also
suggests that new routing metrics, like max residual feasible path and routing, using call
statistics, should be used in order to improve the VoIP performance.
VoIP traffic has its own characteristics regarding its packet size, number of packets
per second, inter-packet delays and it is also dependent on the type of codec being used.
VoIP characteristics, as explained by [13], show that on the G.729 VoIP, payload can be 10,
20, 30 or 40 bytes, but the default is 20 bytes. Since VoIP uses the RTP on the application
which uses a header of 12 bytes, UDP on the transport layer with a header of 8 bytes, and IP
on the network layer, with a header of 20 bytes, it totals 40 bytes of RTP/UDP/IP headers.
Now, if a VoIP payload of 20 bytes is added, it totals to 60 bytes, without the consideration
of data link headers. G.729 codec with the 20 bytes VoIP payload requires 50 packets to be
sent per second. The number of packets can change if the VoIP payload increases or
decreases, but for a normal calculation, 50 packets per second is considered to study the
VoIP traffic. Also VoIP conversations have speech periods and silence periods. Studies
show that if VoIP applications use the voice activity detection, and during the silent periods,
voice packets are not sent, it saves the bandwidth about 35% for an average volume of 24
14
calls simultaneously. Studies [54] show that the VoIP inter-packet delay, which is delay
time between transmitted packets, and the next packet in the queue, is usually between 10
and 30ms. The inter-packet delay time can even increase when the back-off algorithms
sense that the medium is busy.
Researches have tried to identify VoIP flows in real time, in order to manage
network traffic issues, prioritize VoIP flows, reserve bandwidth or block calls to certain
destinations. These efforts face a number of challenges, like usage of non-standard
protocols or ports, non-standard codecs, payload encryption and silence suppression. The
research shows that the nature of human conversation makes the VoIP traffic patterns
different and unique, compared to other applications. Therefore, a flow identification using
the human conversation can provide more promising results than other VoIP flow
identification methods. The study also shows that when two persons, A and B, talk to each
other, their conversation can be modeled in four states: A talking, B talking, both A and B
talking, both silent. The Markov 4-state chain can model these states.
Studies show that VoIP conversations are made up of periodic talk-spurts and
silence gaps, since human conversations have talk periods and silence periods. A study
conducted by [16] states that voice conversations can be distinguished by two types of voice
streams, considering different voice codecs. One type of codec generates constant bit traffic
streams, like the G.711 codec, while the second type of stream uses the codec that uses the
silence suppression and generates active (on) and inactive (off) streams on the G.729 B and
G.723.1 codecs. From a modeling point of view, the second type of stream has significance
and most technologies use this type of streaming to translate a human conversation into a
VoIP stream.
WMN QoS is usually affected by delay and packet loss [18]. Usually one-way delay
of 200 ms, and less than 5% packet loss, is acceptable in VoIP conversations [3]. Besides,
the IEEE 802.11e standard which addresses the QoS, is not designed for ad-hoc WMNs,
therefore VoIP implementation in WMNs cannot be supported by QoS standards [39].
Researchers are suggesting ways to improve QoS. A study by [18] on 15 mesh
nodes, using the common G.729 codec, with 20 byte VoIP payload, transporting 50 packets
per second, shows that by taking the VoIP silence period into account, the utilization of the
bandwidth can be increased by up to 30%. The silence periods, where no packets are sent,
are natural in VoIP conversations. This study also shows that in order to improve service
quality and mesh network capacity, several methods, like multiple interfaces, label-based
forwarding architecture and packet aggregation, can be used. Among all the methods, this
15
research emphasizes that label-based forwarding is the most appropriate method for
improving the VoIP applications. Another study by [28] suggests that using packet
aggregations in IEEE 802.11, WMNs can be a promising solution for VoIP applications.
Since VoIP applications are using many small packets with huge headers, if multiple small
packets can be assembled in one packet with an aggregated header, it will reduce the MAC
layer and physical layer overheads, and it will save the transmission time.
2.4 Wireless mesh and VoIP QoS
WMNs are used by various real-time applications, including VoIP. Research show that the
critical metrics and factors that affect QoS in WMNs are delay, jitter, packet loss and
bandwidth [34] [40] [25]. There are other hidden factors as well, like mobility, obstacles
and weather conditions that affect the link quality [30]. Although the 802.11T standard for
measuring QoS is underway, there is still a lack of industry standards for measuring
wireless mesh QoS factors [34]. Mobility is one of the main factors of measuring mesh QoS
[1] but it is one of the most complicated and challenging factors to measure. Also, WMNs
lack resource management, which results in poor QoS for end users. Therefore, QoS issues
require innovations and research [51] [2] [25].
Prior to implementing VoIP applications, it is important to understand and test
whether the existing networks can support VoIP applications. A study by [35] states that
VoIP applications are susceptible to delay, jitter and packet loss. These factors can make the
VoIP applications unacceptable for average users if they are not in the applications‟
acceptable ranges. Jitter with variation of less than 100ms, can be afforded by jitter buffers.
The acceptable rate for packet loss varies from codec to codec, but the general trend should
be to achieve zero packet loss.
Multi-channel multi-hop mesh networks are not feasible to support VoIP
applications. A study by [10] shows that mesh nodes need to switch from one channel to
another channel in order to communicate with the neighbors, but the current switching
schedules do not consider the requirements of real time traffic, like VoIP. When the nodes
switch from one channel to another channel, there are several phases before the new channel
is used and each phase takes its own time. These phases include: sending buffered frames
into the hardware queue of the Network Interface Card (NIC); stopping interrupt service
routines and sensing the medium; the DCF (Distributed Coordination Function) protocol
with RTS/CTS (Request to Send/ Clear to Send), which requires time, due to back-off
16
algorithms, before data is sent to the newly switched channel. If the duration of all these
phases and processes is added, it will not make the multi-channel multi-hop networks
favorable for VoIP applications. The study suggests that instead of the round-robin method,
a new QoS-aware scheduling method, which uses the packet header to prioritize traffic, can
to be used.
Packet aggregation can even result in further delay. Research by [33] explains VoIP
applications work step by step, by first sampling voice signals, digitizing and encoding
them, then encapsulating the encoded data into packets, using the RTP/UDP and IP. The de-
packetization process happens onthereceiver‟sendand the data is forwarded to the play-
out buffer in order to compensate for the resulted jitter. There are various methods to boost
the VoIP performance, but using the packet aggregation on the G.729 codec with 20 bytes
of VoIP payload and 50 packets per second, can reduce the bandwidth utilization, due to
large protocol headers. Although these protocol headers can be aggregated, it can result in
further delay in some cases, because once the VoIP packets are generated, they are not
immediately transmitted, but kept for other packets to aggregate with.
Nodes‟ mobility can affect the performance of mesh routing protocols and QoS. A
study by [1] explains that the movement of the ad-hoc devices, which is referred to as
nodes‟ mobility, can introduce a number of challenges, like network topology changes,
increase in frequency of route disconnections and packet loss that affect QoS. The study
suggests a Speed Aware Routing Protocol (SARP) to be used. This protocol reduces the
effects of high mobility, and results in a reduced number of route disconnections and packet
losses.
Before a mesh routing protocol is selected, the node mobility model has to be
identified. An empirical study by [17] compared DSDV with DSR mesh routing protocols.
The comparison of these routing protocols was done on four-node mobility models. These
are Random Waypoint, Random Point Group Mobility, Freeway Mobility and the
Manhattan Mobility models. The Manhattan Mobility model, explains the mobile nodes‟
movement pattern in urban areas with vertical and horizontal streets. In this research, UDP
traffic was generated and exchanged among the mesh nodes. The research results show that
DSR performs better than DSDV in high mobility networks, since DSR has faster route
discovery, compared to DSDV, when the old route is not available.
Researchers are actively working to find better solutions for the provision of QoS in
WMNs, which is a challenging task [40] [25]. In wireless networks, when the mobile nodes
move around the cells or to another access point, the session that is currently in progress,
17
should not end or drop off while the node is trying to receive the necessary service from the
new access point. The QoS provisioning should be checked prior to allowing the node to be
associated with new access point. This process is controlled by the call admission control
(CAC) algorithm. This algorithm assigns bandwidth to new connections, based on the
traffic type of the new connection and the current connections. The challenge to the
algorithm is that it should admit as many connections as possible, considering the minimum
call dropping rate, low association, handover latency and efficient bandwidth allocation.
Another method to provide QoS is to adapt scaling of bandwidth rate, based on the traffic
priority [1] [7], but this method requires significant computation on the heavily loaded
networks, which results a considerable delay [20].
Statistical reference models can be created off-line to help select better routes for the
mesh nodes. The proposed solution by [12] is the conservative and adaptive quality of
service (CAQoS) method. This method's central focus is a statistical reference module
(SRM), which provides QoS. The SRM decides how and when the bandwidth should be
scaled-down for the new connection. It gathers information from the application profile,
type of traffic and the status of the network, from both the neighboring base-station and the
mobile terminal in three intervals (peak, moderate and off-peak). It then creates three
separate QoS provision models, according to the number of calls and their traffic conditions
over a period of time. These models are then referenced in future call admissions. Each
model is created and optimized off-line. Therefore, while calls are in progress, they are not
affected by the delays at the time of creating these models.
In order to measure the QoS factors, different methods and tools are used to conduct
the tests. Some researchers have developed their own testing and measurement tools, while
some researchers have used on-the-shelf tools, like Iperf, Rude and Crude, STG (Send
Traffic Grapher), and RTG (Receive Traffic Grapher) [52].
Measuring delay can be done by either calculating one-way or two-way delay. One-
way delay is the time that expires between a packet entering the mesh backbone and leaving
the mesh backbone. One-way delay can also be used as routing metric to select the optimal
route for the real-time traffic. There are two simple methods of measuring one-way delay.
One method is to add a time stamp to each packet that is sent and subtract the reception
from the transmission time, or to use the Round Trip Time (RTT) and divide it by two, to
find the one-way delay. The second method is to send pair packets (PP) one after the other,
and timestamp each packet. Packets are queued, and the time between when the first packet
is received and the second packet is processed and calculated. The problem with the above
18
two methods is that when the time stamp is used, all the nodes‟ clocks must be
synchronized, either by NTP (Network Time Protocol) or GPS (Global Positioning
Satellite), which is practical in a test bed, but not in 'real' life. Furthermore, the
measurement results with RTT do not show each forwarding node‟s delay. The other
problem is that probe messages are smaller in size and do not know how to simulate the real
payload. Another algorithm is the adaptive per hop differentiation (APHD). This algorithm
uses the packet headers to calculate the inter-node (time it takes for a packet to move from
one node to the next node) and the intra-node (the processing time of a packet in a network
card driver of a node, till it gets routed to the next node). APHD uses the packet header
fields to calculate the delay and hops up to this point, while the packets get routed within
the mesh network [25].
Measuring Jitter can be done in various ways. Jitter can occur between the wireless
mesh nodes in a bit level or packet level. One reason is that the circuit that is being used for
voice and video is shared among other applications as well. So, on the same channel or
medium that the voice or video traffic is transported, other data is also transported. This can
result in resources being used by other traffic, while the voice and video traffic will have to
wait their turn in the queue [27]. The process results in the introduction of jitter among the
packets, leaving the queues at different time intervals and reaching their destinations at
various times. A study by [48] explains acceptable jitter rate for voice is less than 100ms. If
the rate goes beyond this limit, it becomes difficult for the jitter buffer to compensate and
VoIP quality starts degrading. Jitter can also be calculated by using timestamps on the IP
header; the time that a subsequent packet reaches its destination is subtracted from the time
that a previous packet reaches it, and jitter between successive packets can be estimated.
Packet loss measurement can be done in several ways. Packet loss can occur due to
various reasons. It can be due an unreliable medium, unreliable protocol, buffer overflow,
resource limitation, link congestions, channel errors, contention between hops [19], etc. A
packet loss can result in portions of data not reaching the destination, and since most of the
real-time applications use the UDP as the transport protocol, data recovery will not happen
if packets are lost. As a result, the voice or video quality will degrade. Packet loss can be
calculated by comparing the number of sent packets from the source node with the number
of received packets at the destination node.
Measuring bandwidth can be done with monitoring software that shows the
device‟s interface usage. Usually Simple Network Management Protocol (SNMP) is used to
monitor the interface usage. The unit of measurement for the bandwidth is bits per second
19
(bps). Since links are usually working with bandwidths above 1024 bps, measurements are
usually done using Kbps (Kilo bits per second), Mbps (Mega bits per second) and Gbps
(Giga bits per second). The achievable bandwidth is called throughput. Throughput is
always less than, or equal to the maximum bandwidth of a link. The best practice to
calculate bandwidth is to transfer a large file over a link and divide the file size by the
amount of time elapsed to download the file, which will show the real data rate of a link.
This is referred to as the goodput. Goodput is usually less than bandwidth and throughput.
2.5 Summary
In this chapter the research community‟s efforts on VoIP implementation over WMNs with
an emphasis on QoS, was explored. The literature shows that WMNs‟ multi-hop nature,
medium usage method and the lack of QoS mechanism in the mesh nodes, lead to
introducing more delay, jitter and packet loss. Each mesh node treats a VoIP and a non-
VoIP packet equally and priority is not given to the sensitive traffic. Although the research
community is actively working on ways to solve these problems, their proposed methods
are not yet fully addressing all these issues. Therefore, VoIP applications are still facing a
number of challenges in WMNs. These challenges are identified as increased delay, jitter,
packet loss and throughput in WMNs. Therefore more research on the subject is required to
determine which of VoIP QoS factors are most affected and how these factors impact the
VoIP quality, considering the WMNs‟ implementation scenarios. In order to investigate
this, the literature survey discussed WMNs‟ characteristics, WMNs‟ scenarios and VoIP‟s
characteristics. Based on the characteristics of WMNs and VoIP, traffic profiles can be
designed in order to simulate and test the resulting impacts on QoS. The next chapter
focuses on the research methodology, problem statement, VoIP and non-VoIP profiles,
simulation software and simulation cases.
21
3 Methods
The research framework used to analyze VoIP QoS in WMNs is presented in this chapter.
This chapter's structure is as follows: Section 3.1 presents the research approach and the
problem statement. Section 3.2 presents the experimental design, the simulation
environment, mesh topology, mesh routing protocol, VoIP and non-VoIP traffic profiles.
Section 3.3 presents the WMN simulation scenario designs, considering three scenarios.
These three scenarios are the no mobility, limited mobility and full mobility scenarios.
Section 3.4 presents the data collection methods and techniques. Finally, Section 3.5
summarizes this chapter.
3.1 Research approach
Referring back to related work, it was stated that the IEEE 802.11e standard, which
addresses QoS in wireless networks, is designed for single-hop. Since WMNs are of a
multi-hop nature, the IEEE 802.11e standard cannot be applied to them, because it can lead
to more delay, jitter, packet loss and improper bandwidth allocation issues, compared to
single-hop [44],[40],[25]. It was shown that these factors cause QoS problems for VoIP
applications. WMNs‟ unique characteristics, due its dynamic formation, multi-hop nature
and node mobility, were discussed in the previous chapter. VoIP traffic‟s unique
characteristics, which are due to human conversation nature and the way conversation is
translated, using various codecs and the presence of talk periods and silence periods, were
also shown. Implementing VoIP applications in WMNs introduces a number of challenges
and issues with QoS. Therefore, this research focuses on the following question: How is
VoIP applications’ QoS affected by wireless mesh node mobility?
The methodology for research in Computer Science is usually defined as either
theoretical or empirical (experimental). Theoretical research is usually conducted by
collecting mathematical, logical and conceptual proof. Empirical research is conducted by
the “building of, or experimenting with or on, nontrivial hardware or software systems”
[36]. Since the aim of this research is to discover the problems that VoIP applications
experience in WMNs, and to measure quantities of delay, jitter, packet loss and bandwidth,
an empirical study is required in order to discover the actual effects of these factors on
service quality in WMNs [37]. Figure 3-1 summarizes the over view of research approach.
This methodology is based on an experimental study, as used by [47] [32] [17]. In this
22
research, wireless mesh nodes are used to produce VoIP traffic, using a single-channel
multi-hop mesh network. Data collection, measurements and statistics are done on source
and destination nodes. The focus is on finding the amount of delay that is caused by the
number of hops; amount of jitter produced as a result of multiple hops and transmission
delay; the number of packets lost among the nodes; and bandwidth used at each node by
VoIP applications.
Figure 3-1 Overview of research approach
The literature survey in Chapter 2 showed that not much work has been done by
other researchers addressing these types of questions and problems in WMNs, especially
when the mesh nodes are partially or fully mobile. The literature survey also indicates that
QoS for VoIP traffic still remains a problem among the research community and more
research is required to understand and investigate how the WMN affects different types of
traffic. This research's aim is to investigate and discover the problems that can affect the
VoIP implementations. VoIP implementation will be studied in three different WMN
scenarios. Since the 802.11e is not supporting QoS in WMNs, there will be no QoS
provisioning done among the wireless mesh nodes. This thesis analyzes the major factors
which may result in poor QoS in real-time applications, like delay, jitter, packet loss and
bandwidth, if they are not within acceptable limits. The analysis will be based on these
major QoS factors for VoIP traffic only, and this research aims to discover whether VoIP
applications can be successful in various scenarios in WMNs.
How does Wi-Fi mesh network
affect VoIP traffic?
Experimental Design
Traffic Generation and simulation
Data Collection
Analysis
Conclusion
Research Approach
23
3.2 Experimental design
The experimental design in this research considers the usage of a single-channel multi-hop
WMN on 802.11b IEEE standard. This standard has been selected on the basis of its wider
availability on various devices. By using this standard in the experimental design, it is easy
to discover how the lower bandwidth rates affect the VoIP traffic in WMNs, because higher
bandwidth standards usually allocate more bandwidth to transport more data among the
nodes, but lower bandwidth standards have to work with complex queues, and deal with
delay, jitter and packet loss. The 802.11b standard will be deployed among 26 nodes, which
will be simulated by simulation software, named NCTUns version 6.0. Going forward,
Section 3.2.1 presents the simulation environment, Section 3.2.2 discusses the mesh
topology, Section 3.2.3 explains which mesh routing protocol is used in this research and
Section 3.2.4 presents the VoIP and non-VoIP traffic profiles.
3.2.1 Simulation environment
In order to build a WMN for conducting various experiments, the NCTUns simulation/
emulation software [53] was selected, because the simulation software has the capability to
simulate WMN and it has a better interface and is less complex compared to other
simulation tools. With this simulation software WMNs have been designed and test cases
were set up in order to analyze VoIP traffic behavior on WMNs. The NCTUns 6.0
simulation/emulation software simulates the wireless mesh clients. It also facilitates the use
of real-world traffic generation and monitoring tools. Nodes' mobility is simulated with the
nodes moving at an average walking speed of 1.3m per second [31]. In this research
wireless mesh nodes are considered as part of the mesh backbone, like in MANETs. The
IEEE 802.11s standard for WMNs considers the mesh nodes as part of the network
infrastructure. Mesh nodes will be stationary or mobile and the WMN formation will only
be made up of wireless mesh clients. Wireless access points and wireless routers are not
considered to be part of the mesh setup in this research. The mesh network is more of an ad-
hoc type of network. The test cases have been designed in three different scenarios. Each
scenario is tested against two VoIP traffic profiles. Profile one is a simple VoIP
conversation between two mesh nodes without any background traffic. Profile two is VoIP
traffic along with background traffic simulated by Transmission Control Protocol (TCP) in
greedy mode. These scenarios are further explained in the experimental design.
24
The traffic generation tools are used to generate traffic and monitor each node‟s
behaviour, considering the QoS factors. The NCTUns 6.0 only runs in Fedora 12, version
i386 and with kernel version 2.6.28.9. Once the NCTUns 6.0 is installed, it will create its
own NCTUns kernel. After the NCTUns installation is completed, the user has to reboot the
machine. Once the machine reboots, the user can choose to load the NCTUns kernel, as
shown in Figure 3-2.
Figure 3-2 Selecting NCTUns kernel
The Fedora 12 will use the NCTUns kernel and this will enable the NCTUns to
work on its own kernel and enable the simulator to load its required modules. The NCTUns
6.0 has three components that run together to make the simulator work. First, the dispatcher
module, shown in Figure 3-3, and then the coordinator module, shown in Figure 3-4, must
run from the root user. Once the dispatcher and the coordinator run into the memory, then
the NCTUns client module, shown in Figure 3-5, must run from the normal user. Once these
three components are loaded successfully, then the NCTUns interface can be used, as shown
in Figure 3-6.
The NCTUns is a network simulator and emulator, capable of simulating various
protocols used in both wired and wireless IP networks. Its core technology is based on the
novel kernel re-entering methodology invented by Prof. S.Y. Wang, while pursuing his
Ph.D. degree at Harvard University (URL: http://nsl10.csie.nctu.edu.tw/)
25
Figure 3-3 NCTUns dispatcher
Figure 3-4 NCTUns coordinator
Figure 3-5 NCTUns client
Figure 3-6 NCTUns 6.0 workspace
26
3.2.2 Mesh topology
In this research, WMN scenarios consist of 26 nodes, as shown in Figure 3-7. All the nodes
are working in the ad-hoc mode and paired randomly and manually. The 26 nodes cover an
area of almost 132248 m2 (y = 488m, x= 271m).
Figure 3-7 Wi-Fi mesh topology for 26 nodes
Each node's physical and channel model parameters are set according to Figure 3-8.
Figure 3-8 Mesh node’s physical layer and channel model parameters
3.2.3 Mesh routing protocol
The NCTUns simulation software is running the God routing protocol (GodRP) in the mesh
nodes. It calculates the best theoretically possible route to other nodes [15] [52], as
discussed in the literature survey. In NCTUns the GOD's routing table is built using the
single-hop and multi-hop routing tables, which is the most accurate method. GOD also
y=488m
x=271m
27
calculates routes without introducing routing overhead(s). As seen in Table 1, the mesh
nodes are communicating with each other randomly. Each mesh nodes is configured with an
IP address: node 1‟s IP address is 1.0.1.1, node 2‟s IP address is 1.0.1.2 and node 26‟s IP
address is 1.0.1.26.
Table 1 VoIP random pairing
Speaker
1
Node
1
Node
2
Node
3
Node
4
Node
5
Node
6
Node
7
Node
8
Node
9
Node
10
Node
11
Node
12
Node
13
Speaker 2
Node 25
Node 15
Node 26
Node 14
Node 22
Node 21
Node 18
Node 16
Node 17
Node 24
Node 20
Node 19
Node 23
3.2.4 Traffic profiles
A VoIP profile was designed to simulate two persons talking to each other, using a wireless
mesh enabled device, such as a desktop, laptop, VoIP phone, handheld device, etc. For
example, a mother talking to her child, where the mother does most of the talking, is
simulated. During the VoIP conversation there are occasions when mother (speaker 1) and
child (speaker 2) are both talking at the same time, mother is talking and child listening,
child is talking and mother listening, or both mother and child are silent. While speaker 1 is
talking, the mesh node is sending VoIP traffic to speaker 2 and the traffic goes across the
mesh network to reach speaker 2. Mostly, when speaker 1 speaks, speaker 2 listens, and
vice versa. Speaker 1 is selected in a sequences from 1 to 13 while speaker 2 is randomly
selected. This model of communication is based on the Markov model, discussed in the
literature survey.
As discussed in the literature survey, in a normal VoIP conversation, using the
common G.729 codec, the voice coder sends 50 VoIP packets every second while the
speaker is talking, but when the speaker is silent, no packet is sent [13] [3] [18] [29]. The
VoIP payload can vary according to the codec setting, but by default the G.729 sends a
payload of 20 bytes (20ms of VoIP conversation) in each IP packet. The payload size can
vary between 10, 20, 30, 40 and 50 bytes. This research considers VoIP payload size of 20,
30 and 40 bytes. Therefore, in 10 seconds of a VoIP conversation, 500 packets must be sent.
The literature survey shows that when the packets are being transmitted from the source to
the destination, there is an inter packet delay (IPD) time. The inter packet delay time is
considered to be between 0.01 and 0.05 seconds. VoIP software uses the RTP in order to
transport voice traffic over UDP and IP. Each one of these protocols has its own headers.
RTP has a header of 12 bytes, UDP has a header of 8 bytes and IP, a header of 20 bytes. If
the size of all these headers is calculated, it will be 40 bytes in total. As the literature survey
shows, a VoIP payload can be either 20, 30 or 40 bytes. If the RTP/UDP/IP headers are
28
added to this, it will total 60, 70 and 80 bytes respectively. According to Table 2, the packet
size of 60, 70 and 80 bytes, will be considered in simulating the VoIP payload along with
the RTP/UDP/IP headers.
The literature survey also shows that VoIP conversations are made up of periods
when the speaker talks, pauses and listens. When the speaker talks, voice is detected by the
codec and then transformed to digital form. Voice traffic is packetized and sent to the other
party (listener). When the speaker pauses or listens to the other speaker, the voice detection
algorithms used by the codec, recognize the pauses and listening periods and mark them as
silent periods. During this time, no traffic is sent to the other party. The non-silence and
silence periods are simulated as the ON and OFF modes where, in the ON mode, the
packets are sent, and in the OFF mode, no packets are sent. This simulation is based on
studies discussed in the literature survey.
In VoIP profile, the mother and child conversation starts with a short greeting.
During the greeting, mother and child talk for almost 10 seconds each. Here both nodes are
talking and generating traffic, therefore both are set to the ON mode. Then they pause for 2
seconds, the OFF mode, and then the mother starts talking for 30 seconds, the ON mode,
while the child is listening, the OFF mode. This conversation continues for some time with
a sequence of ON and OFF states. Then the mother says good-bye to her child, the child
responds with a goodbye and the conversation ends. This conversation lasts 562 seconds. In
total the mother generates approximately 18250 packets and the child generates 7500
packets for the whole conversation. These numbers are just estimated, and in real life
applications, this number can change. When voice traffic is packetized, it can have varying
sizes. The number may increase or decrease depending on the codec being used, considering
the G.729 codec. VoIP profile for a human conversation is designed, using the Markov
model as show in Table 2.
29
Table 2 VoIP profile of human conversation
In order to simulate a human conversation, a traffic generation tool that can simulate
a human VoIP conversation by generating packets with varying sizes, varying inter packet
delays and simulating ON and OFF periods, has to be used. To achieve this, STG and RTG
tools have been selected. The STG tool is used to send traffic and the RTG is used to
receive traffic. The STG can be used in several modes, like TCP, UDP and configuration. In
this research STG is used with the configuration mode. In the configuration mode, a script
can be written which can translate the human conversation in Table 2 into a form where the
STG tool can read the script and generate the traffic as per the defined VoIP parameters for
a human conversation. There are two STG scripts created for speaker 1 (Figure 3-9) and
speaker 2 (Figure 3-10).
Node A Mother (Speaker 1)
Traffic
Direction
Node B Child (Speaker 2)
Tra
nsm
issi
on
stat
us
Tim
e in
sec
Num
ber
of
Pac
ket
s
Time delay in
sec between
each packet
Packet size Description
Tra
nsm
issi
on
stat
us
Tim
e in
sec
Num
ber
of
Pac
ket
s
Time delay
in sec
between
each packet
Packet size Description
Min Max Av
g Min Max Min Max Avg Min Max
ON 10 500 0.01 0.05 70 60 80 Mother Greeting <--------> ON 10 500 0.01 0.05 70 60 80 Child Greeting
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 30 1500 0.01 0.05 70 60 80 Mother talking --------> OFF 30 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 45 2250 0.01 0.05 70 60 80 Mother talking --------> OFF 45 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 60 3000 0.01 0.05 70 60 80 Mother talking --------> OFF 60 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 30 0 0 0 0 0 0 Mother listening <--------- ON 30 1500 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 45 2250 0.01 0.05 70 60 80 Mother talking --------> OFF 45 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 30 1500 0.01 0.05 70 60 80 Mother talking --------> OFF 30 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 45 2250 0.01 0.05 70 60 80 Mother talking --------> OFF 45 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 60 3000 0.01 0.05 70 60 80 Mother talking --------> OFF 60 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 30 0 0 0 0 0 0 Mother listening <--------- ON 30 1500 0.01 0.05 70 60 80 Child Talking
OFF 3 0 0 0 0 0 0 Mother listening ---------- OFF 3 0 0 0 0 0 0 Child pauses
ON 45 2250 0.01 0.05 70 60 80 Mother talking --------> OFF 45 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother pauses ---------- OFF 2 0 0 0 0 0 0 Child listening
OFF 15 0 0 0 0 0 0 Mother listening <--------- ON 15 750 0.01 0.05 70 60 80 Child Talking
OFF 2 0 0 0 0 0 0 Mother listening ---------- OFF 2 0 0 0 0 0 0 Child pauses
ON 5 250 0.01 0.05 70 60 80 Mother Good bye --------> OFF 5 0 0 0 0 0 0 Child listening
OFF 2 0 0 0 0 0 0 Mother listening <--------- ON 2 100 0.01 0.05 70 60 80 Child Good bye
OFF 2 0 0 0 0 0 0 Mother Hangs up OFF 2 0 0 0 0 0 0 Child Hangs up
Total 564 18250 Total 564 7500
30
Figure 3-9. Speaker 1 STG configuration script
Figure 3-10. Speaker 2 STG configuration script
The configuration file parameters for speaker 1‟sconfiguration script are explained below:
Type: udp It specifies which protocol to use. Since UDP is used, it is set
to UDP type.
start_time: 1 This sets the time when the stg should start transmitting the packets,
defined as 1 second in this case.
on-off: 1 This defines how many times this script should run. It is set to 1, since the
script will run once from "on" till the "end".
on: packet: 500 This sets the transmission mode to on and 500 packets will be sent.
uniform: 0.01 0.05 This sets the inter packet delay time for a minimum of 0.01 seconds
and a maximum of 0.05 seconds.
length: exponential This sets the size of the packet, which is an average of 70, with a minimum
31
of 60 and maximum of 80 bytes.
off: time: 2 This sets the transmission to OFF mode, where no packets will be
sent for a period of 2 seconds.
A non-VoIP profile is simulated using the STCP (Sent Transmission Control Protocol) and
RTCP (Receive Transmission Control Protocol) traffic generation tools. Here a simple TCP
greedy traffic mode was used, where the tool establishes numerous TCP connections
between the two communicating nodes and transmits TCP data and it is not limited to a file
size. This traffic was transferred on the opposite flow to simulate the background traffic and
keep all the nodes busy.
3.3 Scenarios
The test cases of VoIP only and VoIP, with non-VoIP traffic profiles, will be simulated in
three different scenarios. These scenarios are organized in a series of sections. Section 3.3.1
presents the no mobility scenario, which is designed and configured to simulate all nodes
in stationary/fixed mode. Section 3.3.2 presents the limited mobility scenario, which is
designed and configured to simulate 10 nodes moving at a walking speed of 1.3m/sec, while
the other 16 nodes are stationary. Section 3.3.3 presents the full mobility scenario,
designed and configured to simulate all nodes moving at a walking speed of 1.3m/sec. Each
scenario is tested against two types of traffic profiles and run 20 times to achieve accurate
results. The first profile is scripted to generate VoIP traffic only and the second profile is
scripted to generate VoIP and non-VoIP traffic. In profile 1, only RTP/UDP/IP traffic is
generated by the simulation tool. In profile 2 both RTP/UDP/IP and TCP traffic are
generated by the simulation tools. Figure 3-11 summarizes the scenarios and traffic profiles.
Figure 3-11 Summary of different scenarios
Scenarios
No Mobility
VoIP Traffic Only
UDP Traffic
VoIP and Non-VoIP
Traffic
UDP+TCP Traffic
Limited Mobility
VoIP Traffic Only
UDP Traffic
VoIP and Non-VoIP
Traffic
UDP+TCP Traffic
Full Mobility
VoIP Traffic Only
UDP Traffic
VoIP and Non-VoIP
Traffic
UDP+TCP Traffic
32
3.3.1 No mobility scenario
This scenario is designed to simulate a WMN with 26 mesh nodes. These nodes are a
distance apart as seen in Table 3. The 26 nodes are all stationary and each node
communicates with another node in the mesh network, i.e. there are 13 mesh node peers
communicating with each other. Two traffic profiles on this type of WMN will be tested.
Table 3 Mesh nodes’ distances in stationary position in metres
The no mobility scenario with VoIP only profile (Figure 3-12), simulates a WMN where the
nodes are communicating with each other, without any background traffic. Each node is
talking to another node, simulating a VoIP conversation. Nodes are randomly selected
according to Table 1. One node is acting as speaker 1, while the other node is acting as
speaker 2. In each node, an STG (Send Traffic Grapher) service is running to send VoIP
traffic and an RTG (Receive Traffic Grapher) service is running to receive VoIP traffic.
Meanwhile, logs are collected during the VoIP conversations to analyze how the
communication is proceeding, whether packet losses, jitters and delays are occurring and
No de
NameN 1 N 2 N 3 N 4 N 5 N 6 N 7 N 8 N 9
N
10
N
11
N
12
N
13
N
14
N
15
N
16
N
17
N
18
N
19
N
2 0
N
2 1
N
2 2
N
2 3
N
2 4
N
2 5
N
2 6
N 1 0 74 80 145 173 236 271 333 379 419 75 140 234 321 419 138 152 217 309 384 479 198 228 294 376 458
N 2 74 0 73 88 144 185 236 284 340 370 133 150 223 300 292 208 199 234 307 371 461 260 268 310 379 452
N 3 80 73 0 83 93 162 191 256 299 341 88 77 159 243 340 171 136 161 239 309 402 207 197 237 309 386
N 4 145 88 83 0 77 97 154 196 254 282 171 130 162 224 311 254 211 204 249 301 384 288 260 272 323 385
N 5 173 144 93 77 0 86 98 168 206 250 163 81 85 155 249 241 174 135 171 228 316 255 203 197 245 310
N 6 236 185 162 97 86 0 79 99 162 185 244 168 135 157 228 324 260 210 209 236 306 342 284 258 279 322
N 7 271 236 191 154 98 79 0 88 108 160 255 161 82 77 157 327 247 168 137 156 231 327 248 196 203 242
N 8 333 284 256 196 168 99 88 0 80 86 331 243 171 132 159 408 332 257 211 200 241 414 337 280 266 279
N 9 379 340 299 254 206 162 108 80 0 74 262 265 172 95 80 430 345 253 177 137 162 422 331 253 213 207
N 10 419 370 341 282 250 185 160 86 74 0 413 321 236 168 139 468 406 320 251 209 212 486 400 326 287 271
N 11 75 133 88 171 168 244 255 331 362 413 0 98 199 290 389 82 77 158 260 341 439 127 155 231 320 408
N 12 140 150 77 130 81 168 161 243 265 321 98 0 101 192 291 165 92 84 169 246 344 174 130 160 236 318
N 13 234 223 159 162 85 135 82 171 172 236 199 101 0 91 190 260 173 86 86 149 244 250 166 123 160 228
N 14 321 300 243 224 155 157 77 132 95 168 290 192 91 0 99 349 261 162 83 79 160 334 238 157 134 165
N 15 419 392 340 311 249 228 157 159 80 139 389 291 190 99 0 447 356 254 155 82 82 426 325 229 163 132
N 16 138 208 171 254 241 324 327 408 430 486 82 165 260 349 447 0 92 197 304 389 488 72 156 256 353 445
N 17 152 199 136 211 174 260 247 332 345 406 77 92 173 261 356 92 0 105 212 297 396 82 78 167 262 354
N 18 217 234 161 204 135 210 168 257 253 320 158 84 86 162 254 197 105 0 107 192 291 172 79 77 162 251
N 19 309 307 239 249 171 209 137 211 177 251 260 169 86 83 155 304 212 107 0 85 184 274 170 76 74 149
N 2 0 384 371 309 301 228 236 156 200 137 209 341 246 149 79 82 389 297 192 85 0 99 359 253 152 80 85
N 2 1 479 461 402 384 316 306 231 241 162 212 439 344 244 160 82 488 396 291 184 99 0 456 349 245 154 79
N 2 2 198 260 207 288 255 342 327 414 422 486 127 174 250 334 426 72 82 172 274 359 456 0 108 214 311 405
N 2 3 228 268 197 260 203 284 248 337 331 400 155 130 166 238 325 156 78 79 170 253 349 108 0 106 203 297
N 2 4 294 310 237 272 197 258 196 280 253 326 231 160 123 157 229 256 167 77 76 152 245 214 106 0 97 191
N 2 5 376 379 309 323 245 279 203 266 213 287 320 236 160 134 163 353 262 162 74 80 154 311 203 97 0 94
N 2 6 458 452 386 385 310 322 242 279 207 271 408 318 228 165 132 445 354 251 149 85 79 405 297 191 94 0
33
whether they are within the acceptable limits for voice communication. The VoIP only
profile sends UDP traffic. VoIP conversations among the nodes start at varying intervals.
Table 4 shows the time when the VoIP conversation starts.
Figure 3-12 No mobility, VoIP only profile
According to Table 4, the RTG service starts once the simulation is run. Since the RTG
service is only aimed at receiving the VoIP traffic generated by STG, this service must start
before the STG starts sending traffic. This is why the start time for RTG is set to zero
seconds. The STG services start one after the other and there is a difference of only one
second between the starting time of each node's STG service.
Table 4 Nodes VoIP Communication. (starting time in seconds)
No Speaker 1 Speaker 2
STG service
Start time in sec
RTG service
Start time in sec
1 Node 1 Node 25 1 0
2 Node 2 Node 15 2 0
3 Node 3 Node 26 3 0
4 Node 4 Node 14 4 0
5 Node 5 Node 22 5 0
6 Node 6 Node 21 6 0
7 Node 7 Node 18 7 0
8 Node 8 Node 16 8 0
9 Node 9 Node 17 9 0
10 Node 10 Node 24 10 0
11 Node 11 Node 20 11 0
12 Node 12 Node 19 12 0
13 Node 13 Node 23 13 0
34
A delay of 1 second has been configured, since in the real world, the VoIP communication
does not start at the same time in all nodes. Each node might start its VoIP conversation at a
different starting time. Therefore Node 1 starts sending VoIP traffic 1 second after the
simulation starts, while Node 13 starts sending VoIP traffic 13 seconds after the simulation
starts. As an example, the following commands are used in the simulation software to
generate VoIP only traffic in Node 1, which is communicating with Node 25. All the
remaining nodes are configured with the same commands.
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
Commands’ Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig1.cfg It is the configuration script file for speaker 1
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving (listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
35
-p It sets the receiving (listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o Writes the per packet throughput log into a file, named thrlog25
The no mobility scenario VoIP and non-VoIP profile is designed to simulate a VoIP
conversation running, while background traffic is also transported by WMN. The VoIP
traffic is generated according to Figure 3-9‟s configuration script. The non-VoIP traffic is
generated using the STCP and RTCP packet generation tool, using the TCP greedy mode.
Figure 3-13 shows a screenshot of the VoIP and non-VoIP profile simulation. .
Figure 3-13 VoIP and non-VoIP profile simulation
As an example, when Node 1 communicates with Node 25, two types of traffic are
transported between these two nodes. Node 1 is having a VoIP conversation with node 25
using the RTP/UDP/IP and meanwhile both nodes are having TCP connection for a file
transfer from Node 25 to Node 1. The commands used to simulate this test case, are as
follows:
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
rtcp -p 5000 -w rtcplog1
Commands Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
36
spkrconfig1.cfg It is the configuration script file for speaker 1
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving (listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
rtcp Receiving TCP traffic
-p It sets the listening port to 5000
-w It writes the per second throughput results in a file named rtcplog1
----------------------------------------------
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
stcp -p 5000 1.0.1.1
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving (listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o It writes the per packet throughput log into a file, named thrlog25
stcp Sends TCP traffic in greedy mode
-p Sets the destination port to 5000
1.0.1.1 The destination (receiving) node's IP address
3.3.2 Limited mobility scenario
37
This scenario is designed and configured with 10 nodes, moving at a walking speed of
1.3m/sec, while the other 16 nodes are stationary. The aim of the scenario is to discover the
effects of mobile nodes on VoIP traffic. The moving nodes' position information during the
simulation time is shown in Table 5. The limited mobility scenario‟s simulation design
screen shot is shown in Figure 3-14.
Table 5 Limited mobility scenario nodes’ movement information
No Node
Name
Position/
Time Coordinate Values (X , Y in metres and T in seconds)
1 Node 2
X 271 310 692 642
Y 43 109 112 39
T 282.359 341.329 635.185 703.248
2 Node 5
X 693 645 273 306 515
Y 106 37 43 107 112
T 141.591 206.247 492.438 547.828 708.644
3 Node 8
X 274 315 697 650 359
Y 41 112 112 39 43
T 61.7113 124.779 418.625 485.411 709.278
4 Node 9
X 691 647 277 308
Y 106 39 39 107
T 298.542 360.2 644.816 702.303
5 Node 11
X 271 227 275 685 720 659
Y 181 250 310 304 235 175
T 297.86 360.81 419.916 735.335 794.849 860.667
6 Node 13
X 270 230 280 690 720 659 457
Y 181 254 313 310 241 169 176
T 145.631 209.662 269.152 584.545 642.422 715.011 870.489
7 Node 16
X 662 271 230 280 691 720
Y 172 181 250 313 311 238
T 59.4899 360.339 422.079 483.948 800.106 860.528
8 Node 21
X 280 692 721 666 272 231
Y 316 313 238 172 178 250
T 73.2387 390.17 452.025 518.112 821.224 884.959
9 Node 23
X 682 721 662 272 233 284 583
Y 302 235 170 181 250 317 311
T 87.0897 146.724 214.25 514.369 575.338 640.108 870.155
10 Node 25
X 684 722 665 270 223 282 376
Y 304 232 167 178 238 310 311
T 244.626 307.251 373.753 677.717 736.345 807.95 880.262
The limited mobility scenario's VoIP only profile is designed in order to simulate a
VoIP conversation between mesh nodes without any background traffic. As an example,
Node 1 and Node 25 are carrying a VoIP conversation. The commands used to simulate this
scenario are as follows:
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
Commands Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig1.cfg It is the configuration script file for speaker 1
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
38
Figure 3-14 Limited mobility scenario VoIP only profile
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
---------------------------------------------
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o It writes the per packet throughput log into a file, named thrlog25
39
The limited mobility scenario's VoIP with non-VoIP profile is designed to simulate a
scenario where mesh nodes are carrying voice conversations and at the same time
transporting non-VoIP traffic, while a number of mesh nodes are moving. In this scenario,
10 mesh nodes are configured to move at a walking distance of 1.3m/sec. As an example,
when Node 1 communicates with Node 25, there are two types of traffic transported
between these two mesh nodes. Node 1 is having a VoIP conversation with node 25 and
transporting RTP/UDP/IP traffic and meanwhile both nodes are having a TCP connection
for a file transfer from Node 25 to Node 1. The commands used to simulate this test case are
as follows:
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
rtcp -p 5000 -w rtcplog1
Commands Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig1.cfg It is the configuration script file for speaker 1
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
rtcp Receiving TCP traffic
-p It sets the listening port to 5000
-w It writes the per second throughput results in a file named rtcplog1
-----------------------------------------------
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
stcp -p 5000 1.0.1.1
40
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o It writes the per packet throughput log into a file, named thrlog25
stcp Sends TCP traffic in greedy mode
-p It sets the destination port to 5000
1.0.1.1 The destination (receiving) node's IP address
3.3.3 Full mobility scenario
This scenario is designed and configured to simulate all mesh nodes moving at a walking
speed of 1.3m/sec. This scenario's node movement information is shown in Table 6. The
mesh nodes are moving in horizontal and vertical paths, which are pre-defined. The network
design screenshot is shown in Figure 3-15.
41
Table 6 Full mobility scenario's mesh node movement position information
No Name
Position
/Time
X 642 273 309 690
Y 42 42 107 106
T 51.6932 336 393 685.774
X 273 309 687 642
Y 41 106 107 39
T 280.796 338 629 691.446
X 696 647 274 314 606
Y 106 38 39 112 109
T 72.4548 137 424 487.883 713
X 270 315 691 647 553
Y 41 106 109 35 42
T 215.434 276 565 631.712 704
X 695 640 270 317 514
Y 103 32 40 112 110
T 143.085 212 497 562.993 715
X 269 314 693 645 458
Y 39 110 109 37 41
T 141.572 206 498 564.337 708
X 698 653 274 316 417
Y 106 40 39 112 115
T 220.781 282 574 638.552 716
X 270 312 700 649 356
Y 42 107 110 35 41
T 64.8394 124 423 492.607 718
X 698 650 269 308
Y 106 37 40 106
T 303.925 369 662 720.638
X 310 700 647 271
Y 112 112 37 39
T 70.1857 370 441 730.064
X 269 233 283 685 719 661
Y 178 250 316 307 238 172
T 299.33 361 425 734.253 793 861
X 271 234 281 689 719 662 562
Y 176 250 317 307 235 172 173
T 222.469 286 349 663.006 723 788 865.286
X 274 234 287 691 721 663 466
Y 179 248 316 307 238 170 176
T 142.476 204 270 580.992 639 708 859.228
X 272 234 284 689 724 661 373
Y 179 253 319 308 238 173 179
T 74.4208 138 202 513.757 574 644 865.177
X 232 283 699 727 665 280
Y 256 316 307 235 170 176
T 72.0166 133 453 512.091 581 877
X 664 272 228 279 688 712
Y 172 178 247 314 310 238
T 58.5071 360 423 487.802 802 861
X 322 632 322 623
Y 241 242 242 241
T 229.277 468 706 937.741
X 322 521 325 521 324 522
Y 244 242 244 241 247 244
T 148.589 302 452 603.238 755 907
X 645 410 645 417 648 414
Y 238 241 242 244 239 244
T 182.314 363 544 719.26 897 ###
X 639 321 639 322
Y 238 239 239 241
T 243.107 488 732 976.19
X 287 699 721 670 273 238
Y 316 308 232 172 179 253
T 76.5298 394 454 514.948 820 883
X 725 666 279 239 284 684
Y 235 170 181 253 317 304
T 58.5071 126 424 487.203 547 855
X 694 727 674 276 233 282 574
Y 307 232 173 178 253 316 304
T 96.5959 160 221 526.811 593 655 879.512
X 693 728 664 282 234 286 475
Y 301 238 169 181 251 314 310
T 177.03 232 305 598.853 664 727 872.397
X 694 729 663 278 239 280 375
Y 304 238 169 181 253 316 317
T 252.318 310 383 679.531 743 800 873.42
X 689 724 671 282 237 284
Y 305 235 172 178 256 316
T 320.778 381 444 743.575 813 871
15
23
24
25
26
17
18
19
20
21
22 Node 22
Node 23
Node 24
Node 25
Node 26
Values (X, Y in metres, T in seconds)
Node 16
Node 17
Node 18
Node 19
Node 4
Node 5
Node 6
Node 7
Node 8
Node 9
Node 1
Node 2
Node 3
Node 21
Node 10
Node 11
Node 12
Node 13
Node 14
Node 15
1
2
3
4
Node 20
16
5
6
7
8
9
10
11
12
13
14
42
Figure 3-15 Full mobility scenario
The full mobility scenario's VoIP only profile is designed and configured in order to
simulate a VoIP only profile, where mesh nodes are only involved in VoIP conversation,
while the nodes are moving. As an example, Node 1 and Node 25 are carrying VoIP
communication between each other. The commands used to simulate this scenario are as
follows:
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
Commands Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig1.cfg It is the configuration script file for speaker 1
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
43
----------------------------------------------
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o It writes the per packet throughput log into a file, named thrlog25
The full mobility scenario's VoIP and non-VoIP profile is designed and configured
to simulate mesh nodes' VoIP conversations while the nodes are carrying non-VoIP traffic,
by establishing a TCP session. All mesh nodes are moving at the same time. As an example,
when Node 1 communicates with Node 25, there are two types of traffic exchanges between
these two nodes. Node 1 and 25 are having a VoIP conversation and transporting
RTP/UDP/IP while both nodes are having TCP sessions for a file transfer from Node 25 to
Node 1. The commands used to simulate this scenario are as follows:
Node 1 configuration:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
rtcp -p 5000 -w rtcplog1
Commands Description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig1.cfg It is the configuration script file for speaker 1
44
-p It is an option to set the destination port, which is 4000
1.0.1.25 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog1
-o It writes the per packet throughput log into a file, named thrlog1
rtcp Receiving TCP traffic
-p It sets the listening port to 5000
-w It writes the per second throughput results in a file named rtcplog1
----------------------------------------------
Node 25 Configuration:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
stcp -p 5000 1.0.1.1
Commands description:
stg The send traffic grapher
-i It sets the stg mode to configuration file
spkrconfig2.cfg It is the configuration script file for speaker 2
-p It is an option to set the destination port, which is 4000
1.0.1.1 It is the destination (receiver) IP address
rtg Receive traffic grapher
-u It sets the rtg mode to UDP mode
-p It sets the receiving(listening) port to 4000
-w It writes the packet log into a log file, named pktlog25
-o It writes the per packet throughput log into a file, named thrlog25
stcp It sends TCP traffic in greedy mode
-p It sets the destination port to 5000
1.0.1.1 The destination (receiving) node's IP address
45
3.4 Data collection
For data collection purposes, the traffic generator and simulation software capabilities were
used to log the traffic generation results. The STG and RTG traffic generation tools have the
capability to write the logs into a file. The RTG usage options are shown in Figure 3-16.
Figure 3-16 RTG usage options
In each mesh node the RTG service is running and the traffic that is sent by the
STG, is logged in a text file. The RTG log file sample is shown in Figure 3-17. This log file
shows the average packet loss and average delay.
Figure 3-17 RTG log file content
The throughput logs are extracted from the NCTUns using its throughput logging
capability. A log file is generated as shown in Figure 3-18. All the throughput log files are
imported into an Excel file and then the average throughput is calculated in Kbps for each
node, since NCTUns log the throughput in terms of Kbps.
46
Figure 3-18 Throughput logging in NCTUns
Jitter rate is calculated from the packet log. Each packet is numbered in a sequence and is
time-stamped. All the packet logs are separately imported for each node into an Excel file.
Next, the packet log is sorted by sequence number. The time difference between the first
and second packet received, is then calculated. This method is used for all the packets in the
log file. In the end, the average time difference between all the packets is calculated.
3.5 Summary
This chapter presented the methods and steps used to run the three WMN scenarios. Each
scenario was tested against two simulation cases or traffic profiles. The simulation cases
reflected VoIP and non-VoIP traffic profiles. The three scenarios' simulation cases were
designed and configured to simulate mesh nodes in stationary mode (No mobility), 10
mobile mesh nodes and 16 stationary nodes (Limited mobility) and all mesh nodes mobile
(Full mobility). The VoIP profile was based on a simple voice conversation between a
mother and a child, which was converted into a VoIP traffic profile, based on human
conversation VoIP characteristics and patterns. The VoIP conversation duration was 562
seconds, which included the talk periods and the silent periods. During the talk period, VoIP
packets were exchanged between the VoIP peers using STG and RTG traffic generation
tools, and during the silent period no VoIP packets were sent. The non-VoIP traffic profile
was simulated using STCP and RTCP in greedy mode. Data collection was done on the
source and destination nodes using the STG and RTG and simulation software logging
capabilities during the simulation process.
48
4 Analysis of results
The analysis of results is based on simulation scenarios that were used to collect the
required logs, statistics and data from each of the mesh nodes. The NCTUns simulation
software was configured to generate logs for analyzing the VoIP QoS factors of delay, jitter,
packet loss and throughput. The STG and RTG tools packet and throughput logging
options, along with mesh nodes‟ logging features, were used to collect such logs. Each of
these factors is analyzed separately in this chapter. First, each scenario's delay, jitter, packet
loss and throughput results were analyzed for each one of the traffic profiles and finally all
scenarios were compared considering delay, jitter, packet loss and throughput results for all
the traffic profiles. To present the analysis of the results, this chapter is structured as
follows: Section 4.1 presents the analysis of no mobility scenario with each VoIP QoS
factor analyzed separately. Section 4.2 contains an analysis of the VoIP QoS factors for the
limited mobility scenario, with each factor analyzed separately. Section 4.3 presents the
analysis results for the full mobility scenario. Again all the VoIP QoS factors are analyzed
and discussed separately. Section 4.4 contains a synthesis of the results, with an analytical
comparison of the three scenarios and with corresponding traffic profiles. Finally, Section
4.5 contains a summary of the analyses.
4.1 No mobility scenario results
The analysis of delay, jitter, packet loss and throughput in the no mobility scenario, shows
whether the results of the simulation cases are in acceptable range for the VoIP QoS factors.
According to the literature survey, the acceptable range for VoIP QoS factors is defined as
less than 200ms delay, less than 100ms jitter, and up to 5% packet loss.
Delay analysis for VoIP only profile (No mobility UDP) shows that delay is very
low and does not exceed the VoIP acceptable limit of less than 200ms, therefore the delay
factor is not an issue in this scenario. The second profile, simulating the VoIP and non-VoIP
traffic (No mobility UDP+TCP), shows that adding the TCP as the background traffic,
affects the delay factor to a large extent. It also shows that delay increases and even exceeds
the VoIP QoS limit of 200ms. In this test case, the delay even exceeds 2000ms. There are
only 5 nodes that have a delay of less than 200ms.The reason is that these nodes are located
close to each other, i.e. they are only one hop away. It is clear that mixing TCP traffic with
VoIP applications, will not be a sensible implementation, as VoIP applications will become
unusable.
49
Figure 4-1 No mobility scenario: Delay analysis
Jitter analysis for the no mobility scenario is shown in Figure 4-2. The VoIP only profile
was compared to the VoIP and non-VoIP profiles. The comparison shows that the VoIP
only profile has a lower jitter rate than VoIP with non-VoIP profile, but both scenarios'
results show that the jitter limits of VoIP are not exceeded. All the jitter rates are less than
100ms, which is the acceptable jitter rate for VoIP. Therefore jitter rate doesn't seem to be a
big a concern in this scenario. The results show that VoIP implementation without the
background traffic performs much better than having background traffic like TCP, but even
so, the jitter rate does not cross the acceptable rate for VoIP.
The packet loss analysis for the no mobility scenario is shown in Figure 4-3. The
two scenarios, VoIP-only profile, and VoIP and non-VoIP profiles, were compared.
According to the graph, a VoIP only profile, where there is no background traffic, has
almost no packet loss or very little loss compared to a VoIP profile mixed with background
traffic. If background traffic is added, the packet loss rate increases and the graph shows
that the packet loss rate reaches as much as almost 80%, while the acceptable packet loss
rate for VoIP application is less than 5%. It can be concluded that packet loss rate with
VoIP only profile is at acceptable range for VoIP traffic, but mixing VoIP traffic with non-
VoIP traffic, renders the VoIP implementation unusable.
0
500
1000
1500
2000
2500
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay i
n m
s
Nodes
No mobility scenario delay analysis
No Mobility UDP No Mobility UDP+TCP
50
Figure 4-2 No mobility scenario: Jitter analysis
Figure 4-3 No mobility scenario: Packet loss analysis
The throughput analysis for the no mobility scenario is shown in Figure 4-4. Here
a comparison of a VoIP only profile with VoIP and non-VoIP profile is done. As the graph
shows, the VoIP only profile requires very low bandwidth to transport VoIP packets, since
VoIP packets are very small. A simple calculation shows that for a normal VoIP
conversation with G.729 codec, 50 packets per second have to be sent. Each packet will
have an average size of 70 bytes, which will contain the RTP/UDP/IP data and headers. If
the maximum packet size of 80 bytes is considered, then 4000 bytes per second have to be
sent. To send 4000 bytes per second, a bandwidth of 32 kbps is required. If it is roughly
calculated, and layer two encapsulation is considered, together with a bandwidth of 35-
0
5
10
15
20
25
30
35
40
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Jitt
er i
n m
s
Nodes
No mobility scenario jitter analysis
No mobility UDP No mobility UDP+TCP
0
10
20
30
40
50
60
70
80
90
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay in
ms
Nodes
No mobility scenario packet loss analysis
No mobility UDP No mobility UDP+TCP
51
40kbps, it will be enough for a successful VoIP conversation. As the graph shows, the VoIP
only profile (No mobility UDP) performs well and it uses as much bandwidth as required by
the VoIP application. The bandwidth usage is around 40-45 kbps. Looking at the VoIP and
non-VoIP profile, with the TCP as the background traffic, the bandwidth usage increases.
Once TCP starts sending and exchanging traffic, bandwidth is allocated to TCP traffic and
there are chances that lower bandwidth is allocated to VoIP application/traffic. Although the
bandwidth usage is high, VoIP traffic still uses normal packet queues and is mixed with
TCP traffic. This increases delay and jitter and even packet loss. Since the packets are
delayed, they will be timed out and will be of no use by the VoIP applications. It can be
seen in the graph that the VoIP only profile, uses lower bandwidth, but performs well, since
the bandwidth is not shared with other non-VoIP applications.
Figure 4-4 No mobility scenario: Throughput analysis
4.2 Limited mobility scenario analysis
As discussed in Section 3.3.2, only 10 mesh nodes were configured to move at a walking
speed of 1.3m/sec. In this scenario, nodes 2, 5, 8, 9, 11, 13, 16, 21, 23 and 25 are moving.
Each one of the VoIP QoS factors like delay, jitter, packet loss and throughput are analyzed.
This scenario is set up in two separate profiles. One is a VoIP only profile and another one
is a VoIP and non-VoIP traffic profile. In this scenario both traffic profiles are analyzed and
their effect on VoIP QoS factors is investigated.
Delay analysis for VoIP only profile is shown in Figure 4-5. This analysis show that
VoIP only profile (Limited mobility UDP) performs well and the delay does not exceed the
acceptable limit of less than 200ms. Although some of the mesh nodes' delay increased due
0
200
400
600
800
1000
1200
1400
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
Thro
ughp
ut
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Thro
ugh
pu
t in
kb
ps
Nodes
No mobility scenario throughput analysis
No mobility UDP No mobility UDP+TCP
52
to the mobility factor, the delay still falls in the acceptable range for VoIP. It is clear that the
delay factor is affected by node mobility. It can also be seen that the VoIP only profile
performs well and VoIP applications can run successfully in these scenarios.
If the VoIP traffic is mixed with non-VoIP traffic (Limited mobility UDP and TCP),
it shows that there is a considerable variation in the delay time. Delay exceeds the
acceptable VoIP limit of less than 200ms, and even reaches 2000ms in one case. As in a
previous scenario, nodes 7, 8 and 19 again experience delay of less than 200ms. The reason
is that these nodes are only one hop away from their communication nodes. These 3 nodes‟
delay results show that although VoIP and non-VoIP traffic is mixed, the delay is still in an
acceptable range for VoIP, since these nodes are not multiple hops away. It is also observed
that nodes 6, 8, 11, 16, 15, 17, 20 have lower delay than in the no mobility UDP and TCP
scenario, because their communication nodes are coming closer as the nodes move.
Figure 4-5 Limited mobility scenario: Delay analysis
Jitter analysis for the limited mobility scenario is shown in Figure 4-6. According
to the achieved results from limited mobility simulation and VoIP only profile with VoIP
and non-VoIP profile, it is evident that there is much difference in the jitter values of these
two profiles. Even so, the jitter values on both profiles do not cross the acceptable jitter
limit for VoIP of less than 100 msec. In summary, the jitter factor will not be of much
concern in VoIP implementation in both traffic profiles. Also, these values are not much
different than the no mobility scenario for VoIP and non-VoIP profiles.
0
500
1000
1500
2000
2500
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay in
ms
Nodes
Limited mobility scenario delay analysis
Limited mobility UDP Limited mobility UDP+TCP
53
Figure 4-6 Limited mobility scenario: Jitter analysis
Packet loss analysis for the limited mobility scenario is shown in Figure 4-7. It is
evident that in the VoIP only profile, nodes that are moving are affected by greater packet
loss. The packet loss can either be seen on the moving nodes themselves or their associated
hosts, with which they are communicating. Table 7 shows the communicating peers, and
from these peers only nodes 2, 5, 8, 9, 11, 13, 16, 21, 23 and 25 are moving. The packet loss
graph shows that nodes 2, 5, 8, 9 and 11 which are moving, experience packet loss, and
nodes 1 and 6 also experience packet loss, since their associated communicating nodes, 25
and 21 respectively, are also moving. It is also observed that nodes 3, 7 and 10 experience
packet loss, due to the fact that the nodes through which they are communicating, nodes 13,
21 and 25, are moving. The graph also shows that nodes 2, 5 and 8 crossed the acceptable
packet loss rate of 5% for VoIP applications.
Table 7 Limited mobility nodes’ communication peers Speaker
1
Node
1
Node
2
Node
3
Node
4
Node
5
Node
6
Node
7
Node
8
Node
9
Node
10
Node
11
Node
12
Node
13
Speaker 2
Node 25
Node 15
Node 26
Node 14
Node 22
Node 21
Node 18
Node 16
Node 17
Node 24
Node 20
Node 19
Node 23
In the VoIP and non-VoIP traffic profile simulation results, a huge packet loss can
be seen, compared to VoIP only profile. This is due the TCP background traffic. Most of the
nodes have crossed the acceptable packet loss rate of 5%. Only nodes 4, 7, 12 and 18 have a
less than 5% packet loss and this is due to the fact that these nodes are communicating with
the hosts that are only one hop away, or are located closer. From this analysis, it can be
concluded that mobility results in packet loss. In a VoIP only profile, the packet loss is
mostly at an acceptable rate, although in some cases, it can be unacceptable. Also, mixing
0
5
10
15
20
25
30
35
40
45
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Jitt
er
in m
s
Nodes
Limited mobility scenario jitter analysis
Limited mobility UDP Limited mobility UDP+TCP
54
non-VoIP traffic with VoIP traffic can greatly affect VoIP conversation, which makes the
VoIP implementation in these environments unusable, despite the fact that a few nodes
which are one hop away, or located close to their VoIP peers, can have packet loss at
acceptable rates.
The throughput analysis of the limited mobility scenario profiles is shown in
Figure 4-8. The graph shows that the VoIP only profile uses very low throughput, since the
VoIP packets are very small. Some nodes, where their communicating nodes are moving
and in the process moving closer to their peers, can benefit from higher bandwidth. The
graph also shows that nodes 20, 21, 23, 24 and 25 are using higher bandwidth, since during
the movement process, they come closer to their communicating nodes. Node 24 is also
benefitting from higher bandwidth, since its routing node, node 24, is moving closer at one
point and then moving closer to node 10, which is communicating with node 24, at another
point of the movement.
Figure 4-7 Limited mobility scenario: Packet loss analysis
Figure 4-8 Limited mobility scenario: Throughput analysis
0
10
20
30
40
50
60
70
80
90
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Pac
ket
loss
%
Nodes
Limited mobility scenario packet loss analysis
Limited mobility UDP Limited mobility UDP+TCP
0
200
400
600
800
1000
1200
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ughp
ut
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ughp
ut
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Thro
ugh
pu
t in
kb
ps
Nodes
Limited mobility scenario throughput analysis
Limited mobility UDP Limited mobility UDP+TCP
55
The profile for VoIP traffic mixed with non-VoIP, shows that throughput usage
reaches a very high level, since TCP is using most of the available bandwidth. The way
resource allocation is done for TCP and UDP, can result in less throughput allocation to
VoIP traffic, which can result in further delay, jitter and packet loss. Only nodes which are
located close to each other, or a hop away, can benefit from higher throughputs of above
800 Kbps, while the rest of the nodes are allocated lower throughputs. It can be concluded
that in VoIP only profile, all of the throughput is allocated to VoIP traffic. Therefore it
performs well and uses as much bandwidth as required, but usually bandwidths of 40-45
Kbps are enough for a successful VoIP conversation. Looking at the VoIP and non-VoIP
profile mixed traffic patterns, it is evident that most of the bandwidth is used by the non-
VoIP profile. Since there is no QoS mechanism implemented among the mesh nodes, VoIP
traffic uses the normal queues, which can result in delay, jitter and packet loss. The analysis
of delay, jitter and packet loss, also confirms this problem.
4.3 Full mobility scenario analysis
In the full mobility scenario, all mesh nodes are moving at a walking speed of 1.3m/sec.
This scenario consists of two profiles. One is a VoIP only profile, where all mesh nodes are
only involved in VoIP conversations and there is no background traffic. The second is a
profile mixed with VoIP and non-VoIP traffic. An analysis of VoIP QoS factors, delay,
jitter, packet loss and throughput, proves that they are exceeding acceptable ranges.
A delay analysis for the full mobility scenario is shown in Figure 4-9. The graph
shows that delay for VoIP only profile is not crossing the VoIP delay limit of 200ms.
Movement information of nodes is shown in Table 6 on page42. Referring to the second
profile in which VoIP traffic is mixed with non-VoIP traffic, it can be seen that the delay
exceeds the acceptable limit of 200ms. The delay reaches as high as about 1200 seconds.
Only node 7 is an exception. It has a delay of around 21ms, which is due to its close
proximity to its communicating host, which is node 18, and which is only one hop away. It
can be concluded that if nodes are mobile and they are only carrying VoIP traffic and no
background traffic exists, then VoIP implementations can be successful. But if nodes are
carrying a mix of VoIP and non-VoIP traffic, it will make the VoIP applications unusable.
56
Figure 4-9 Full mobility scenario: Delay analysis
Jitter analysis for the full mobility scenario is shown in Figure 4-10. As the graph
shows, jitter values of the VoIP only profile falls within the acceptable jitter limit of VoIP,
which is less than 100ms. Looking at the jitter rates of VoIP, mixed with non-VoIP traffic,
it can be seen that the jitter rates are higher. Despite the higher jitter rates in the second
traffic profile, it still does not cross the VoIP jitter limit. In conclusion, the node mobility
factor doesn't affect the jitter rate to the extent that would make the VoIP applications
unusable, and although the non-VoIP traffic injection increases the jitter rates, it doesn't
exceed the acceptable limits.
Figure 4-10 Full mobility scenario: Jitter analysis
Packet loss analysis for the full mobility scenario is shown in Figure 4-11. The
graph shows that in the VoIP only profile, packet loss rate in the nodes where the
communicating node is moving away from its peer, is higher than in those nodes where
their communicating nodes are not moving very far from each other. These types of nodes
have also crossed the acceptable packet loss rate for VoIP, which is less than 5%. The graph
0
200
400
600
800
1000
1200
1400
De
lay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay in
ms
Nodes
Full mobility scenario delay analysis
Full mobility UDP Full mobility UDP+TCP
0
5
10
15
20
25
30
35
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Jitt
er i
n m
s
Nodes
Full mobility scenario jitter analysis
Full mobility UDP Full mobility UDP+TCP
57
also shows that nodes 3, 4, 7, 10, 11, 12, 13 and 23 experience a packet loss rate of more
than 5%, while the other nodes‟ packet loss rate is acceptable. Looking at the VoIP traffic
mixed with non-VoIP traffic profile, it can be seen that packet loss rates increase
dramatically due to the non-VoIP traffic existence, which is running as the background
traffic. The result is that all nodes experience packet loss rates of above 5%. According to
above analysis, it can be concluded that VoIP applications in scenarios where all nodes are
mobile and mesh nodes are only exchanging VoIP packets, can be 70% successful,
considering the packet loss factor. Unfortunately, VoIP applications in scenarios where
VoIP traffic is mixed with non-VoIP traffic are completely unusable as a result of the packet
loss factor.
Figure 4-11 Full mobility scenario: Packet loss analysis
Throughput analysis for the full mobility scenario is shown in Figure 4-12. The
graph shows that mesh nodes in the VoIP only profile, only uses very small portions of the
bandwidth required to make a VoIP call, which requires between 40-45 Kbps of bandwidth,
because VoIP packets are very small. Referring to VoIP traffic mixed with non-VoIP traffic,
it can be seen that bandwidth usage rises in most of the nodes and nodes start dedicating
bandwidth for the TCP connections. This results in allocating lower bandwidth than the
VoIP requirement. And besides, the VoIP packets will be using the same queues as other
non-VoIP traffic, which can result in more delay, jitter and packet loss. This happens
because there is no QoS mechanism used in the mesh nodes to tag VoIP traffic and to place
them in the priority queues. In conclusion, VoIP applications perform well considering
bandwidth usage, providing that they are not mixed with other types of traffic, but if they
are mixed with other types of traffic, QoS mechanisms should be implemented among the
nodes.
0
10
20
30
40
50
60
70
80
90
100
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pa
cke
t lo
ss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
Pac
ket
loss
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Pac
ket
loss
%
Nodes
Full mobility scenario packet loss analysis
Full mobility UDP Full mobility UDP+TCP
58
Figure 4-12 Full mobility scenario: Throughput analysis
4.4 Comparative analysis
In this section the different scenarios‟ results are compared to analyse the effect of nodes'
mobility on VoIP QoS. The comparison basis will be QoS factors of delay, jitter, packet
loss and throughput. Each QoS factor and each node's behaviour are compared against all
scenarios. The focus will be on analyzing the effects of limited mobility and full mobility on
the QoS factors, considering the VoIP and non-VoIP traffic profiles.
Delay analysis and a comparison of the three scenarios of VoIP, with its related
traffic profiles, are shown in Figure 4-13. As the graph shows, VoIP only profiles without
background traffic, experience delay lower than 200ms, while scenarios with background
traffic, experience higher delays. The graph also shows that the VoIP only profile‟s delay
values in the three scenarios are not much different, irrespective of the nodes‟ mobility
factor.
Figure 4-13 Delay analysis of all scenarios and traffic profiles
0
100
200
300
400
500
600
700
800
900
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Thro
ugh
pu
t in
kb
ps
Nodes
Full mobility scenario throughput analysis
Full mobility UDP Full mobility UDP+TCP
0
500
1000
1500
2000
2500
Del
ay
Del
ay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay in
ms
Nodes
Delay analysis of all scenarios and traffic profiles
No mobility UDP No mobility UDP+TCP
Limited mobility UDP Limited mobility UDP+TCP
Full mobility UDP Full mobility UDP+TCP
59
Jitter analysis of all three scenarios and their related traffic profiles are shown in
Figure 4-14. The graph shows that the jitter rates of the VoIP-only profile, with no
background traffic, are lower in all the scenarios, but the jitter rate for VoIP and non-VoIP
profile is higher. It can also be seen that in all these scenarios, irrespective of the traffic
profiles and nodes‟ mobility, the jitter rate is below the acceptable limit of 100ms.
Figure 4-14 Jitter analysis of all scenarios and traffic profiles
Packet loss analysis of all the scenarios and their related traffic profiles, are shown
in Figure 4-15. The graph shows that VoIP only profiles, with no background traffic, have
lower packet loss rates than VoIP profiles with background traffic. Among all the scenarios,
the no mobility scenario has the lowest packet loss rate, followed by the limited mobility
scenario, with 10 mobile nodes, and the full mobility scenario, with all mobile nodes. The
graph shows that node mobility results in packet loss. In the scenarios with background
traffic, the full mobility scenario with the highest mobility rate has the highest packet loss
rate as well. There are only a few mesh nodes in the limited mobility and full mobility
scenarios that have lower packet loss. This is due to the fact that these nodes are
communicating with the nodes that are only one hop away. Even when these nodes move,
these values remain the same, since node movement is designed in a way that the nodes
move one after the other, in a linear manner.
0
5
10
15
20
25
30
35
40
45
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Jite
r in
ms
Nodes
Jitter Analysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
60
Figure 4-15 Packet loss % of all scenarios and traffic profiles
Throughput analysis of all three scenarios with their related traffic profiles, are
shown in Figure 4-16. The comparative analysis shows that throughput usage in no
mobility, limited mobility and full mobility with VoIP only profile, is between 40 and
45kbps. The graph shows that scenarios with background traffic have higher throughputs.
Since no QoS mechanism is implemented on the mesh nodes, the VoIP and non-VoIP
traffic share the same queues, which results in delay, jitter and packet loss.
Figure 4-16 Throughput analysis of all scenarios and traffic profiles
A summary of all VoIP QoS factors, with the achieved results and their associated
values for all simulation scenarios and profiles, is shown in Table 8.
-10
0
10
20
30
40
50
60
70
80
90
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Pac
ket l
oss
%
Nodes
Packet loss % Analsysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
-200
0
200
400
600
800
1000
1200
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Thro
ugh
pu
t in
kb
ps
Nodes
Throughput Analysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
61
Table 8 Summary of all VoIP factors for all scenarios and traffic profiles
UDP UDP+TCP UDP UDP+TCP UDP UDP+TCP
Delay (ms) 5 651 4 576 16 475
Packet loss % 0 19 4 42 4 43
Throughput Kbps 45 174 44 269 44 429
Ji tter (ms) 3 20 2 19 3 19
Delay (ms) 5 565 5 843 24 708
Packet loss % 2 5 7 33 3 42
Throughput Kbps 44 410 45 328 44 305Ji tter (ms) 3 20 2 21 3 27
Delay (ms) 7 748 18 1239 27 487
Packet loss % 0 49 4 37 9 57
Throughput Kbps 44 137 44 255 43 108Ji tter (ms) 4 27 4 32 5 20
Delay (ms) 2 129 2 216 8 1208
Packet loss % 0 1 0 2 10 30
Throughput Kbps 44 835 44 1015 45 755Ji tter (ms) 2 18 1 16 2 20
Delay (ms) 8 756 11 1180 3 916
Packet loss % 0 48 7 73 2 20
Throughput Kbps 43 51 46 296 44 456Ji tter (ms) 4 29 3 26 2 23
Delay (ms) 6 1153 3 618 43 700
Packet loss % 0 23 3 39 3 39
Throughput Kbps 43 237 44 325 47 582Ji tter (ms) 3 24 2 21 4 25
Delay (ms) 3 8 14 8 19 22
Packet loss % 0 0 2 0 6 24
Throughput Kbps 42 44 47 43 42 38Ji tter (ms) 2 6 2 6 4 8
Delay (ms) 7 1796 5 478 4 393
Packet loss % 0 23 9 52 4 61
Throughput Kbps 43 229 44 432 44 474
Ji tter (ms) 4 17 2 19 2 15
Delay (ms) 5 470 5 483 27 382
Packet loss % 0 12 2 25 3 26
Throughput Kbps 43 247 42 449 43 702
Ji tter (ms) 3 15 2 18 3 17
Delay (ms) 7 1258 12 873 7 570
Packet loss % 0 63 1 55 5 11
Throughput Kbps 44 36 44 44 42 549Ji tter (ms) 4 33 3 27 3 18
Delay (ms) 6 797 2 558 28 324
Packet loss % 0 80 1 17 6 25
Throughput Kbps 42 39 43 435 41 668Ji tter (ms) 3 25 2 17 4 16
Delay (ms) 2 449 2 480 2 320
Packet loss % 2 10 0 10 6 39
Throughput Kbps 122 932 42 975 49 678Ji tter (ms) 2 14 1 14 1 19
Delay (ms) 3 633 4 640 20 516
Packet loss % 1 18 10 56 9 77
Throughput Kbps 121 1073 46 458 42 407Ji tter (ms) 2 19 2 23 3 21
Delay (ms) 3 1394 2 993 2 662
Packet loss % 0 34 0 26 5 26
Throughput Kbps 45 836 47 1024 42 742Ji tter (ms) 2 29 2 24 1 17
Delay (ms) 4 1574 6 455 6 511
Packet loss % 0 32 5 38 5 37
Throughput Kbps 33 410 44 323 47 315Ji tter (ms) 3 29 8 18 2 19
Delay (ms) 4 274 8 276 12 429
Packet loss % 0 4 6 54 2 59
Throughput Kbps 44 233 41 415 43 455
Ji tter (ms) 2 15 1 19 2 20
Delay (ms) 4 1289 3 537 2 760
Packet loss % 0 16 3 21 2 26
Throughput Kbps 42 254 42 458 45 728
Ji tter (ms) 2 25 2 17 1 21
Delay (ms) 2 9 1 9 9 261
Packet loss % 0 0 0 0 4 20
Throughput Kbps 42 44 53 89 81 55Ji tter (ms) 1 7 1 6 2 13
Delay (ms) 2 252 1 134 18 754
Packet loss % 0 4 0 3 3 44
Throughput Kbps 123 972 56 1028 50 650Ji tter (ms) 1 11 1 9 2 15
Delay (ms) 4 535 2 421 4 765
Packet loss % 0 35 0 17 2 25
Throughput Kbps 124 506 105 590 75 753Ji tter (ms) 2 19 1 15 2 20
Delay (ms) 4 177 3 411 2 639
Packet loss % 0 2 0 30 2 31
Throughput Kbps 125 300 78 461 66 574Ji tter (ms) 2 15 2 15 1 17
Delay (ms) 4 556 11 375 2 548
Packet loss % 0 31 5 67 1 15
Throughput Kbps 44 50 47 283 131 581Ji tter (ms) 2 18 2 20 1 18
Delay (ms) 2 24 31 961 23 815
Packet loss % 0 0 5 66 6 78
Throughput Kbps 122 607 123 401 95 462
Ji tter (ms) 1 8 3 20 3 18
Delay (ms) 5 2105 6 1987 3 472
Packet loss % 0 23 1 58 3 16
Throughput Kbps 287 450 197 591 85 595
Ji tter (ms) 3 28 2 39 2 16
Delay (ms) 4 800 14 1157 15 377
Packet loss % 0 12 3 48 5 45
Throughput Kbps 45 179 191 442 87 443Ji tter (ms) 3 21 2 30 2 19
Delay (ms) 4 552 7 507 11 476
Packet loss % 0 29 2 18 3 53
Throughput Kbps 44 142 45 260 144 358Ji tter (ms) 2 21 2 19 2 20
Node 26
Node 14
Node 15
Node 16
Node 17
Node 18
Node 22
Node 23
Node 24
Node 25
Node 5
Node 6
Node 7
Node 20
Node 21
Node 10
Node 11
Node 12
Node 13
Node 8
Node 9
Node 19
Node 1
Node 2
Node 3
Node 4
Full mobility
Node Name Factor
No mobility Limited mobility
62
4.5 Summary
In this chapter all the simulation case results were analyzed individually and the traffic
profiles within the same and different WMN scenarios, were also compared. . The use of
self explanatory graphs show that VoIP applications‟ successful implementation can be
achieved by isolating VoIP traffic to a separate network, where the resources are not shared
with non-VoIP applications. The findings show that using non-VoIP applications along with
VoIP applications affects all the VoIP QoS factors and makes the VoIP applications
unusable. Table 9 shows the number of nodes exceeding the acceptable VoIP QoS limits in
each scenario and each traffic profile. It also shows that jitter has remained below 100 ms in
all scenarios, while VoIP only profile's delay and packet loss, have crossed the acceptable
limits in a few nodes, which is due to nodes' mobility in the limited and full mobility
scenarios. It is noticeable in both the VoIP and non-VoIP profiles that most of the nodes
experience delay and packet loss higher than the acceptable ranges, which is due to the
existence of the non-VoIP profile.
Table 9 Number of nodes exceeding the acceptable VoIP QoS limits
Scenario Traffic Profile
Delay
>200 ms
Jitter
> 100 ms
Packet loss
> 5%
Total No.
of nodes
No
mobility
VoIP only 0 0 0 26
VoIP + non-VoIP 21 0 19 26
limited
Mobility
VoIP only 0 0 5 26
VoIP + non-VoIP 23 0 22 26
Full
Mobility
VoIP only 0 0 8 26
VoIP + non-VoIP 25 0 26 26
63
5 Conclusion and future work
In this research, the focus was to understand mesh VoIP QoS characteristics by simulating
realistic VoIP conversations over WMNs, with both VoIP and non-VoIP traffic profiles. A
sample conversation of a mother and child was translated into a VoIP conversation applying
the G.729 codec among 26 mesh nodes. These nodes created 13 VoIP peers. These tests
were conducted in three different scenarios and run 20 times. In the no mobility scenario, all
of the 26 nodes were stationary, in the limited mobility scenario, 10 out of 26 mesh nodes
were mobile and in the full mobility scenario, all the mesh nodes were mobile. Each
scenario was tested against two traffic profiles. Profile 1 was VoIP traffic only, using
RTP/UDP/IP where no background traffic was present and only nodes were involved in
VoIP conversations. Profile 2 was VoIP profile mixed with non-VoIP profile, where non-
VoIP profile was simulated by TCP in the greedy mode. The mobile nodes in the limited
mobility and full mobility scenarios were configured to move with a walking speed of 1.3m
per second. The mobility of the nodes were as per a defined path, where the nodes were
starting their movement from their initial positions, moving within the mesh network
coverage and finally coming back from where they had started their movements.
5.1 Research conclusion
The conclusion of this research's results is shown in Figure 5-1. It can be summarized as
follows: A WMN formed by stationary nodes (no mobility) is an acceptable platform for
VoIP implementation, maintaining that there is no background traffic mixed with VoIP
traffic. A WMN formed by a mix of stationary and mobile nodes (limited mobility) can be a
good platform for VoIP implementation, if there is no background traffic mixed with VoIP
traffic. A WMN formed by full mobile nodes is also a good platform for VoIP
implementation, if there is no background traffic mixed with VoIP traffic. VoIP
implementation with background traffic may not be successful if QoS is not implemented
among mesh nodes. The results show that node mobility can result in more packet loss,
compared to a scenario in which nodes are not mobile. If node mobility with a speed of
1.3m/sec can increase packet loss, then high mobility of nodes with faster speeds can
increase the packet loss to the extent that would make the VoIP implementation unusable.
Jitter rate in all the three scenarios didn't cross the acceptable VoIP jitter limit. Therefore a
jitter buffer, which is normally used by VoIP applications, can very well solve the problem
of jitter in VoIP implementations. The research also shows that if the communicating
64
mobile wireless mesh nodes happen to come close to each other, or are only one hop away,
the VoIP conversation can run smoothly even if there is background traffic generated or
processed by the communicating nodes. VoIP conversation requires a throughput of an
average 40-45 kbps. If this much bandwidth could be allocated to the mesh nodes involved
in VoIP conversation, the VoIP traffic throughput requirements of the G.729 codec
characteristics and the VoIP traffic profile used herein will be met. The mobile mesh nodes‟
movement direction has great significance on VoIP QoS. When the mobile nodes are
moving towards the direction of their communicating nodes, the VoIP quality improves, but
when the mesh nodes are moving against the direction of their communicating nodes, the
VoIP quality degrades. Furthermore the movement of mesh nodes serving as the next hop
for the VoIP peers, causes increased delay, jitter and packet loss.
Figure 5-1 Number of nodes exceeding VoIP QoS factor limits
5.2 Recommendations
The following are some recommendations for VoIP implementation over WMNs, based on
the findings of this research. VoIP applications‟ usage in WMNs is considered to be a cheap
solution for rural areas in developing and least developed countries. Urban areas can also
make use of WMN to achieve redundancy and high availability for critical services
including VoIP services. For a successful VoIP implementation, the QoS issues have to be
addressed. Since WMNs currently do not provide QoS capabilities, it is better to create a
physically or virtually separated network for VoIP applications, so that other types of traffic
won't mix with VoIP traffic. Also, routing protocol choice can help to achieve better QoS. It
Delay >200ms
Jitter > 100 ms
Packet loss > 5%
0
5
10
15
20
25
30
VoIP only VoIP + non-VoIP
VoIP only VoIP + non-VoIP
VoIP only VoIP + non-VoIP
No mobility limited Mobility Full Mobility
Delay >200ms 0 21 0 23 0 25
Jitter > 100 ms 0 0 0 0 0 0
Packet loss > 5% 0 19 5 22 8 26
Nu
mb
er
of
no
de
s
Number of nodes exceeding VoIP QoS factor limits
65
is recommended that routing protocols should be selected according to the nodes' mobility
model. In WMNs design, if the nodes‟ moving path could be defined in a way that it moves
towards its communication node, the service quality will increase. Furthermore, mesh
nodes‟ mobility speed should be kept to a minimum, if and when possible.
5.3 Limitations
The following limitations of this research were identified. It was challenging to design the
simulation cases using several mobility models; therefore one mobility model was used.
Test Cases were run in a simulator, not in a real network. Other limitations include time and
hardware constrains to simulate a large WMN of more than 100 nodes and to run test cases
using the GOD routing protocol. In this research mesh nodes‟ formation were by clients
only, no mesh access point and router was used. There was no external interference sources
present in the network designs. The average distance between the buildings and the building
heights, transmit power, street width and path loss exponent were limited to what has been
described in Section 3.2.2. The VoIP profile was scripted to simulate VoIP payload along
with RTP/UDP/IP headers. Layer 2 frame header overhead was not considered. The
simulation cases used only one type of VoIP profile. VoIP traffic parameterization,
considering the common G.729 codec, also proved a challenge. Furthermore, background
traffic simulation using TCP in greedy mode was a challenge.
5.4 Future work
WMNs are newly emerged type of networks. Testing various applications over WMNs is
necessary to discover if WMNs‟ dynamic nature and other unique characteristics result in
better or poorer quality of service compared to normal wireless networks. Focusing research
efforts on VoIP implementation over WMNs should be of special interest to researchers,
due to VoIP‟s sensitivity to delay, jitter, packet loss and throughput usage.
WMN implementation in areas where no network infrastructure exists is an ideal
choice, but using real time applications over these networks is a challenge. Today people
are much more interested in making voice calls instead of video calls, sending e-mails and
chatting with friends. In rural areas of countries like Afghanistan and other least developed
countries, both basic literacy and computer literacy are big challenges, and this has resulted
in widening the digital divide. But today even illiterates can make voice calls, because of its
easy-to-use nature. In rural areas WMNs and VoIP applications are also affected by
66
unavailability of reliable electricity. If the WMN equipment is stationary, it needs to be fed
with reliable electricity, especially if the equipment serves as WMN access points and
gateways. If the WMN equipment is mobile, battery power will have to be used. Since the
WMN nodes are allowing other nodes to make use of their resources, the power
consumption will be higher, resulting in battery powered equipment quickly going offline.,
Since the beauty of WMNs lies in its mobility, which can only be achieved by using a
battery as the power source; future researches should also address power constraint issues.
Future work based on this research can be focused on any of the following: Testing
the same scenarios, but using different WMN routing protocols and analyzing the VoIP QoS
factors. Mesh nodes‟ mobility speed could be modified to a faster speed and its effects on
VoIP QoS factors could be studied. Mesh nodes‟ movement path and direction could be
modified to analyze the effects on VoIP QoS factors. The effect of increasing the number of
mesh nodes on VoIP QoS, could also be determined by adding more nodes in each scenario.
The VoIP profile parameters and characteristics according to other codec types is also a
possible field of study. The mesh nodes could be configured to switch to ON and OFF states
to study how the WMN topology changes and how the VoIP QoS factors are affected. The
influence on VoIP QoS of adding mesh access points and routers as fixed devices could be
determined. Using the NCTUns emulation capabilities to communicate with real networks
and introducing interferences to degrade mesh coverage, are other possible future studies.
Once QoS capabilities are introduced for WMNs, QoS metrics could be configured to
prioritize VoIP traffic on each mesh node and to discover how VoIP QoS is affected.
67
Bibliography
[1] Akunuri, K., Arora, R., & Guardiola, I., G. (2011). A study of speed aware routing for
mobile ad hoc networks. International Journal of Interdisciplinary Telecommunications
and Networking, 3, 40-61.
[2] Akyildiz, I. F., Wang, X., & Wang, W. (2005). Wireless mesh networks: A survey.
Computer Networks, 47(4), 445-485. www.sciencedirect.com
[3] Anand, K., Samrat, G., Samir, R. D., & Suman, B. (2007). VoIP on wireless meshes:
Models, algorithms and evaluation. INFOCOM 2007. 26th IEEE International
Conference on Computer Communications, 2036-2044.
[4] Bahl, P., Adya, A., Padhye, J., & Wolman, A. (2004). Reconsidering wireless systems
with multiple radios. Computer Communications Review, 34(5), 39-46.
http://portal.acm.org
[5] Bakhshi, A., & Prasanna, V., K. (2004). Energy-efficient communication in multi-
channel single-hop sensor networks. Proceedings of the Tenth International Conference
on Parallel and Distributed Systems (ICPADS’04), 403-410.
[6] Bluetooth Inc. (2007). Bluetooth. February/02, 2007,
http://www.bluetooth.com/bluetooth/
[7] Bluetooth, I. (2007). Baseband resource Manager February/04, 2007, from
http://bluetooth.com/Bluetooth/Learn/Works/Core_System_Architecture.htm
[8] Brewer, E., Demmer, M., Du, B., Ho, M., Kam, M., Nedevschi, S., et al. (2005). The
case for technology in developing regions. Published by the IEEE Computer Society,
25-38.
[9] Caprihan, G., Kumar, S., & Saran, H. (1997). A quality of service translation
methodology based on user perception. Proc. IEEE Singapore International Conference
on Networking, Singapore.
[10] Castro, M., C., Dely, P., Kassler, A., J., & Vaidya, N., H. (2009). QoS-aware channel
scheduling for multi-Radio/Multi-channel wireless mesh networks. Proceedings of the
4th ACM International Workshop on Experimental Evaluation and Characterization,
11-18.
[11] Chiueh, T., Raniwala, A., Krishnan, R. & Gopalan, K. (2005). Hyacinth: An IEEE
802.11-based multi-channel wireless mesh network. February/02, 2007, from
http://www.ecsl. cs.sunysb.edu/multichannel/
[12] Choong, K. N., Yee, Y. C., Low, A. L., Chien, S. F., & Ng, S. L. (2006). QoS
provisioning for multimedia wireless networks. BT Technology Journal, 24(2),117-122.
[13] Cisco Systems. (2006). Voice over IP - per call bandwidth consumption. Retrieved
09/22, 2011, from http://www.cisco.com
[14] Cisco Systems. (2011). What is VoIP?, 2011, from www.cisco.com
[15] Clausen, T., & Herberg, U. (2011). Delay tolerant routing with OLSRv2 No.
7662)Institut National De Recherche en Informatique et en Automatique.
[16] Dang, T. D., Sonkoly, B., & Molnár, S. (2004). Fractal analysis and modeling of VoIP
traffic. Telecommunications Network Strategy and Planning Symposium. NETWORKS
2004, 11th International, , 1-8. doi:10.1109/NETWKS.2004.1341826
[17] Divecha, B., Abraham, A., Grosan, C., & Sanyal, S. (2007). Impact of node mobility on
MANET routing protocols models., 1-10.
[18] Dragos, N., Samrat, G., Kyungtae, K., & Rauf, I. (2007). Performance of VoIP in a
802.11 wireless mesh network. Paper presented at the INFOCOM 2006. 25th IEEE
International Conference on Computer Communications, Barcelona, Spain. pp. 1-11.
68
[19] Draves, R., Padhye, J., & Zill, B. (2004). Routing in multi-radio, multi-hop wireless
mesh networks. MobiCom 2004,
[20] El-Kadi, M., Olariu, S., & Abdel-Wahab, H. (2002). A rate-based borrowing scheme for
QoS provisioning in multimedia wireless networks. IEEE Transactions on Parallel and
Distributed Systems, 13(2), 156-166. Retrieved from IEEE Computer Society database.
[21] Galperin, H. (2005). Wireless networks and rural development: Opportunities for latin
america. Information Technologies and International Development, 2(3), 47-56.
[22] Gambiroza, V., Sadeghi, B., & Knightly, E., W. (2004). End-to-end performance and
fairness in multihop wireless backhaul networks. Paper presented at the The 10th
Annual International Conference on Mobile Computing and Networking, Philadelphia,
PA, USA. pp. 287-301. Retrieved from http://portal.acm.org
[23] Ian, A., F. (2005). A survey on wireless mesh network., S23-S30.
[24] Jang, S. (2003). In Kelly B., E., Davis A., W.(Eds.), A technical FAQ: Frequently asked
questions about voice and video over IP networks. MA, USA: Wainhouse Research.
Retrieved from http://www.wainhouse.com/files/papers/wr-faq-ip-conf.pdf
[25] Jian, L., Zhi, L., & Prasant, M. (2008). Adaptive per hop differentiation for end-to-end
delay assurance in multihop wireless networks. Ad Hoc Networks Journal, 7(6), 1169-
1182.
[26] Jun, J., & Sichitiu, M., L. (2008). MRP: Wireless mesh networks routing protocol.
Computer Communications, 31(7), 1413-1435.
[27] Karam, M., J., & Tobagi, F., A. (2002). Analysis of the delay and jitter of voice traffic
over the internet. INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE
Computer and Communications Societies. Proceedings. IEEE, 2, 824-833.
[28] Kaur-Kehal, R., & Sengupta, J. (2011). A comprehensive review on improving QoS for
VoIP in wireless mesh networks. Journal of Global Research in Computer Science, 2,
32-33.
[29] Kim, H., Yun, S., & Lee, H. (2007). Boosting VoIP capacity of wireless mesh networks
through lazy frame aggregation. IEICE Trans. Commun., E90–B, 5, 1283-1285.
[30] Kim, K., & Shin, K., G. (2006). On accurate measurement of link quality in Multihop
wireless mesh networks. Paper presented at the MobiCom '06 Proceedings of the 12th
Annual International Conference on Mobile Computing and Networking, pp. 38-49.
[31] Knoblauch, R., L., Pietrucha, M., T., & Nitzburg, M. (1996). Field studies of pedestrian
walking speed and start-up time. Transportation Research Record, 27-38.
[32] Liese, S., Wu, D., & Mohapatra, P. (2006). Experimental characterization of an 802.11b
wireless mesh network. IWCMC '06 Proceedings of the 2006 International Conference
on Wireless Communications and Mobile Computing, pp. 587-592.
[33] Marwah, K., & Singh, G. (2011). VoIP over WMN: Effect of packet aggregation.
International Journal on Computer Science and Engineering, 3, 2323-2331.
[34] Mlinarsky, F. (2006). The challenges and importance of testing mesh networks prior to
deployment. Rf Design, 29(6), 16-23.
[35] Moskaluk, D. (2007). VoIP using wireless mesh infrastructure. Retrieved 02/2011,
2011, from http://www.moskaluk.com/voip_using_wireless_mesh_infrast.htm
[36] National Academy of Science. (1994). What is experimental computer science and
engineering? [Academic Careers for Experimental Computer Scientists and Engineers]
(pp. 9-9). Washington D.C: National Academy of Sciences.
[37] Olivier, S. M. (2004). Experiments. Information technology research (Second ed., pp.
68-77). Pretoria, South Africa: Van Schaik.
[38] Poe, R. (2007). Mesh wi-fi complicates wireless VoIP use. Retrieved 09/22, 2011, from
http://www.focus.com/briefs/mesh-wi-fi-complicates-wireless-voip-use/
69
[39] Reddy, B., T., John, J., P., & Murthy, S. R., C. (2006). Providing MAC QoS for
multimedia traffic in 802.11e based multi-hop ad hoc wireless networks. Computer
Networks, 154-176. Retrieved from www.sciencedirect.com
[40] Serrano, S., Campobello, G., Leonardi, A., & Palazzo, S. (2011). A MOS-based routing
approach for wireless mesh networks. Paper presented at the pp. 1-6.
[41] Sevanto, J., Liljeberq, M., & Raatikainen, K. (1998). Introducing quality-of-service and
traffic classes into wireless mobile networks., 21-31. Retrieved from ACM database.
[42] Shao, H. (2004). Multimedia QoS support specified in various wireless network
standards. IEEE MultiMedia, 11(4), 75-77.
[43] Shuang, Y. (2011). Extending the base IEEE 802.11™ WLAN standard to include mesh
networking. Retrieved November/07, 2011, http://standards.ieee.org
[44] Strix Systems. (2005). Solving the wireless mesh network multi-hop delimma Strix
System.
[45] Strix Systems. (2006). Next steps in municipal wireless mesh networks. Retrieved 09/22,
2011, from www.wlanmall.com/media/catalog/pdf/strix_muni_mesh.pdf
[46] Tsai, T., & Chen, J. (2005). IEEE 802.11 MAC protocol over wireless mesh networks:
Problems and perspectives. Proceedings of the 19th International Conference on
Advanced Information Networking and Applications (AINA’05), 60-63.
[47] Vasan, A., & Shankar, U., A. (2002). An empirical characterization of instantaneous
throughput in 802.11b WLANs.CS-TR-4389, 1-6.Retrieved from
http://www.cse.iitb.ac.in
[48] VoIP Foro. (2006a). Jitter. Retrieved 2 February 2007,from
http://www.en.voipforo.com
[49] VoIP Foro. (2006b). Latency. Retrieved 2 February 2007, from
http://www.en.voipforo.com
[50] VoIp-info. (2011). Bandwidth consumption., 2011, from http://www.voip-info.org/
[51] Waharte, S., Boutaba, R., Iraqi, Y., & Ishibashi, B. (2006). Routing protocols in
wireless mesh networks: Challenges and design considerations. Multimed Tools Appl,
(29), 285-303.
[52] Wang, S., Chou, C., & Lin, C. (2010). The GUI user manual for the NCTUns 6.0
network simulator and emulator Network and System Laboratory, Department of
Computer Science, National Chiao Tung University, Taiwan.
[53] Wang, S., & Lin, Y. (2005). NCTUns network simulation and emulation for wireless
resource management. Wireless Communications and Mobile Computing, 5, 899-916.
[54] Wang, X., Chen, S., & Jajodia, S. (2005). Tracking anonymous peer to peer VoIP calls
on the internet. Proc. of Computers and Communications Security , pp. 81-91.
[55] Wikipedia Contributors. (2011). Throughput. Retrieved 11/23, 2011, from
http://en.wikipedia.org
[56] WiMAX Spectrum Owners Alliance. (2007). Spectrum. Retrieved February/04, 2007,
from http://www.wisoa.net/site/what-is-wimax/spectrum/
71
Appendix A Unpublished draft paper
Abstract— This paper analyzes the impact upon
quality of service for voice over Internet Protocol on wireless
mesh networks with mobile nodes and simulates voice traffic
on such a mesh network to analyze the following
performance metrics: delay, jitter, packet loss and
throughput. Wireless mesh networks present interesting
characteristics such as multi-hop routing, node mobility, and
variable coverage that can impact quality of service. There
are three wireless mesh network scenarios each with 26 mesh
nodes, a reasonable deployment scenario for a small
organizational network for either urban or rural deployment
has been considered. In first scenario, all mesh nodes are
stationary. In the second scenario, 10 nodes are mobile and
16 nodes are stationary. Finally, in third scenario, all mesh
nodes are mobile. The mesh nodes are simulated to move at a
walking speed of 1.3m per second. The results show that
node mobility can increase packet loss, delay, and jitter.
However, the results show that wireless mesh networks can
provide acceptable quality of service providing there is little
or no background traffic generated by other applications. In
particular, the results demonstrate that jitter across all
scenarios remains within human-acceptable tolerances. It is
therefore recommended that voice over Internet Protocol
implementations on wireless mesh networks with
background traffic be supported by quality of service
standards, otherwise they can lead to service delivery
failures. On the other hand, voice-only mesh networks, even
with mobile nodes, offer an attractive alternative voice over
Internet Protocol platform.
Categories and Subject Descriptors
C.2.1 [Computer-Communication Networks]: Network
Architecture and Design - Wireless Communication
I. INTRODUCTION
his paper presents the analysis of voice over Internet
Protocol (VoIP) applications on wireless mesh
networks (WMNs). The characteristics of WMNs and
VoIP applications cause quality of service (QoS) problems.
Studies show that WMNs unique characteristics is achieved
by combining the wireless ad-hoc network (MANETs),
wireless sensor networks and cellular technologies
features[7][16], meanwhile owning these features result in
QoS issues for VoIP implementations. VoIP applications
characteristics are identified as: sensitivity to delay, jitter,
packet loss and use of small packets. Generally the WMNs
are considered to be a type of mobile ad-hoc network. The
similarities between the two are in multi-hop nature and
nodes mobility, but the differences are in the use of
gateways, traffic flows, nodes mobility, mobile node role and
device energy constrain issues [8] [16].
WMNs usually have dynamic and complex topologies.
The next hop can change from time to time and service
quality may vary based on the speed of nodes movement,
distance from other nodes, obstacles and load on mesh nodes.
The IEEE 802.11s standard for WMNs considers the mesh
nodes as part of the network infrastructure, while mesh nodes
can be stationary or mobile. In this research wireless mesh
networks formations will only be by wireless mesh clients.
Wireless access points and wireless routers are not
considered to be part of the mesh setup in this research. The
designs are a combination WMNs and MANETs. Studies
show that WMNs introduce more delay, jitter and packet loss
and it may be causing problem for the VoIP applications.
This research will mainly focus on studying the VoIP
applications by discovering how this type of traffic is
affected by WMNs. An empirical research by running
simulation cases and generating VoIP traffic and non-voice
traffic will be conducted. The simulation cases are setup with
stationary and mobile nodes.
In order to explain how WMNs affect VoIP
implementations, the remainder of this paper is organized as
follows: Section II discusses the VoIP QoS related works,
Section III presents the research question and methodology,
Section IV explains the results and analysis, finally in
Section V the research will be concluded.
II. RELATED WORK
A WMN is a communications network made up of radio
nodes organized in a mesh topology. WMNs often consist of
mesh clients, mesh routers and gateways. Another good
definition can be: WMNs is a self-healing, self organization
and fault tolerant network with dynamic topologies and
formed by a mix of/only wireless clients, access points
and/or routers. Studies show that real-time traffic in wireless
networks requires QoS (QoS) for prioritization [15]. For this
reason the IEEE 802.11e MAC (Media Access Control)
protocol was proposed to provide QoS. Research done by
[14] confirms that since WMNs are characterized as multi-
hop transmission, the IEEE 802.11e MAC which deals with
QoS does not fit the requirements of backhaul networking in
WMNs.
Routing protocols play a key role in order to facilitate
mesh nodes discovery and communication. Therefore the
routing protocols choice and characteristic can affect the QoS
[8]. There are several important factors for choosing a mesh
routing protocol like size of network, nodes mobility and
type of traffic. Mesh routing protocols are usually classified
as proactive, reactive or hybrid. There are many mesh routing
protocols, but some of them are commonly used which are
listed as follows: B.A.T.M.A.N, DSDV, HSR, IARP, OLSR
and DSR [16]. Another routing protocol named GoDRP
(God Routing Protocol) is also used by simulation software
like ns2 (Network Simulator 2) and NCTUns (National
Chiao Tung University- network simulator) to calculate the
routes based on nodes' position and signal range without any
routing protocol overhead, this type of routing protocol is
used to help and benchmark the simulations to the best way a
routing protocol can theoretically perform [17].
Prior to implementing VoIP applications, it is important
to understand and test the existing networks if they can
support VoIP applications. Research shows that WMNs
characteristics and complexities make it challenging to
implement VoIP applications which are mainly due to delay,
jitter, packet loss, multi-hop path and dynamic nature [7].
Today VoIP applications are widely used, but still there
is lack of QoS for voice applications in the new emerging
WMNs, since VoIP applications are exchanging many small
Mohammad Tariq Meeran and William D. Tucker
Department of Computer Science
University of the Western Cape, Private bag X17, Bellville 7535, South Africa
Tel: +27 21 959 3010, Fax: +27 959 3006
email: {mtmeeran, btucker}@uwc.ac.za
An analysis of Voice over Internet Protocol in wireless mesh
networks
T
73
packets which are made of big packet headers and small
VoIP payloads. Researchers confirm that little efforts has
been dedicated to address and investigate these problems on
wireless multi-hop networks [9][10]. WMNs QoS is usually
affected by delay, packet loss. Usually one-way delay of 200
ms, jitter rate of less than 100ms and packet loss of less than
5% is acceptable in VoIP conversations [2]. Another study
by [6] using the common G.729 codec with 20 byte VoIP
payload, 50 packets per second shows that taking into
account the VoIP silence period can increase the utilization
by up to 30%. The silence periods are natural in VoIP
conversation where no packets are sent. VoIP traffic
characteristics are unique, considering their packet size,
number of packets per second, inter packet delays and
dependencies on the type of codec being used. Studies by [3]
[11] explains that on the G.729 VoIP payload can be 10, 20,
30 or 40 bytes, but the default is 20 bytes. Since VoIP uses
the RTP (Real-Time Transport Protocol) with a header of 12
bytes, UDP (User Datagram Protocol) with a header of 8
bytes and IP with the header of 20 bytes, in total it makes 40
bytes of RTP/UDP/IP headers. Now if a VoIP payload of 20
bytes is added, it sums up to 60 bytes in total without the
consideration of data link headers. G.729 codec with the 20
bytes VoIP payload requires that 50 packets to be sent per
second. The number of packets can change if the VoIP
payload increases or decreases, but for a normal calculation
50 packets per second is used to study the VoIP traffic. Also
VoIP conversation has speech periods and silence periods.
Studies show that if VoIP applications use the voice activity
detection mechanism, and during the silent periods voice
packets are not sent, it saves about 35% of the bandwidth for
an average volume of 24 simultaneous calls. Research by
[19] shows that the VoIP inter packet delay time is usually
between 10 and 30ms. The inter packet delay (IDP) time can
even increase when the back-off algorithms senses that
medium is busy.
Identifying VoIP flows in real-time is important for
researchers in order to manage network traffic issues,
prioritize VoIP flows, reserve bandwidth or block calls for
some certain destinations. The research by [20] shows that
when two persons A and B talk to each other, their
conversation can be modeled in four states: A talking, B
talking, both A and B talking, both silent. These states can be
modeled by Markov 4-state chain. Another study by [4]
shows that VoIP conversations are made of talk-spurts (on
periods) and silence gaps (off periods) on G.729 codec, since
the human conversation also has talk periods and silence
periods.
Nodes mobility can affect the performance of mesh
routing protocols and QoS. Before a mesh routing protocol is
selected the nodes mobility model has to be identified. An
empirical study by [5] has compared DSDV with DSR mesh
routing protocols. The comparison of these routing protocols
was done on four-node mobility models which are Random
Waypoint, Random Point Group Mobility, Freeway Mobility
and the Manhattan Mobility models. The research results
show that DSR performs better than DSDV in high mobility
networks, since DSR is having faster route discovery
compared to DSDV when the old route is not available. VoIP critical metrics and factors that affect QoS in
WMN are delay, jitter, packet loss and bandwidth [13] & [7].
Besides there are other hidden factors as well like mobility,
obstacles and weather conditions that affect the link quality
[11]. Mobility is also one of the main factors of measuring
mesh QoS [1] &[13], but it is one of most complicated and
challenging factors to measure. In order to measure the QoS
factors there are different methods and tools used to conduct
the tests and do the data collections. Some researchers have
developed their own testing and measurement tools and some
researchers have used on the shelf tools like Iperf, rude and
crude [6], RTP, STG, RTG, STCP, RTCP etc. The next
section explains the simulation tools, scenarios and
methodology.
III. METHODOLOGY
Referring back to the literature, it was stated that the IEEE
802.11e standard which addresses QoS in the wireless
networks is designed for single-hop. Since WMNs are of
multi-hop nature, the IEEE 802.11e standard cannot be
applied on time. As a result WMNs can be challenging for
VoIP implementation by introducing delay, jitter, packet loss
and less bandwidth allocation compared to single-hop for
VoIP applications [7] &[13]. Therefore this research focuses
on the answer for the following question:
How are VoIP QoS factors affected by WMNs node
mobility?
Therelatedworksshowthattherehasn‟tbeenmuchwork
done by other researchers addressing this type of problem in
WMNs, especially when the mesh nodes are mobile and
stationary. Also the related work shows that QoS for VoIP
traffic has still remained as a problem among the research
community and more research is required to investigate and
understand how WMNs affect VoIP applications. The related
works also show that researchers are proposing different
solutions, but none of the solutions have solved the problem,
this is due to the fact that more research is require in order to
study and understand the WMNs affects on VoIP QoS. This
research's aim is to investigate and discover the problems
that can affect the VoIP implementations. This research will
study the VoIP implementation in three different WMNs
scenarios. This paper analyzes the QoS critical factors like
delay, jitter, packet loss and bandwidth as discussed in
related work, and discovers the reasons that affect these
factors and why it goes beyond the acceptable limits. This
research measures and analyzes all these critical QoS factors
for VoIP traffic only, and discovers if VoIP applications can
be successful in WMNs considering VoIP and WMNs unique
type, nature and characteristics.
Since the focus is on discovering the problems that VoIP
applications confront when the mesh nodes are moving and
measuring some quantities like delay, jitter, packet loss, and
bandwidth an empirical study is required in order to help us
discover actual affects of WMNs on service quality[5][12]
[15][18]. In this research the wireless mesh nodes have been
configured to generate traffic using single-channel multi-hop
mesh network. Data collecting, measurements and statistics
are based on source and destination nodes. Several QoS
factors will be investigated like the amount of delay that is
caused by number of hops and load, amount of jitter
produced as a result of multiple hops and transmission delay,
number of packets lost among the nodes and bandwidth used
at the each node by VoIP and non-VoIP applications.
Simulation Software choice for this research is the
NCTUns simulation /emulation version 6.0 [18]. This
simulation software enables us to design and simulate
WMNs. Three WMN topologies have been designed and test
cases were run in order to analyze the VoIP applications
behavior considering WMNs nodes mobility in each
scenario.
74
Meanwhile data and statistics are collected in order to
analyze how VoIP QoS factors are affected by comparing
scenarios and traffic profiles. The test cases have been
designed in three difference scenarios, each scenario is tested
against two VoIP traffic profiles. Profile one is a simple
VoIP conversation between two mesh nodes without any
background traffic. Profile
two is VoIP traffic along
with background traffic
like TCP greedy.
Experimental design
in this research based on a
single-channel multi-hop
WMN on 802.11b IEEE
standard. The 802.11b
standard will be deployed
among 26 nodes. Using the
simulator, three WMNs
topologies were designed,
each with 26 nodes. All
the nodes are operating in
ad-hoc mode. The 26
nodes are covering an area
of almost 132248 m2 (y =
488m, x= 271m). Mesh
nodes are running the
GoD routing protocol
[17].
A VoIP profile has
been scripted to simulate two persons talking to each other
using wireless mesh enabled devices. As a test case a mother
talking to her child will be simulated, where the mother does
most of the talking. During the VoIP conversation there are
occasions when mother (speaker 1, Table 1) and child
(speaker 2) are both talking at the same time, mother talking
and child listening, child talking and mother listening, or
both are silent. When speaker 1 talks, the mesh node is
sending VoIP traffic to speaker 2, the traffic will go across
the mesh network to reach speaker 2. Mostly, when
speaker1talks, speaker2 listens, and vice versa, silence
suppression. This model of communication is based on the
Markov model [20].
As discussed in section II, VoIP software usually uses
the RTP protocol in order to transport voice traffic over UDP
and IP. If a VoIP payload size of either 20, 30, 40 bytes is
considered and then the RTP/UDP/IP headers are added to
VoIP payload it will be make 60, 70 and 80 bytes
respectively. In this research the packet sizes of 60, 70 and
80 bytes are considered to simulate the VoIP payload along
with the RTP/UDP/IP headers with 50 packets/sec and IPD
of 0.01-0.05ms.
In VoIP profile, the mother and child conversation flow
can be broken up as follows. Mother starts with short
greetings. During the greeting, both mother and child are
talking for almost 10 seconds. Here both nodes are talking
and generating traffic, therefore both are set to the ON mode.
Then they pause for 2 seconds, the OFF mode, and then the
mother starts talking for 30 seconds, the ON mode, while the
child is listening, the OFF mode. This conversation continues
for some time with a sequence of ON and OFF states and
then the mother says goodbye to her child and the child
responds by a goodbye and the conversation ends.
This conversation takes 562 seconds. In total the mother
generates approximately 18250 packets and the child
generates 7500 packets for the whole conversation. These
numbers of packets are just estimations, and in live
applications it can change, since when the voice traffic is
packetized it can have varying sizes and this number may
increase or decrease depending on the codec being used, here
the G.729 codec is considered.
Now in order to simulation a human conversation, a
traffic generation tool has to be used that can simulate a
human VoIP conversation by generating packets with
varying sizes, varying inter packet delays, simulating ON
and OFF periods. To achieve this, the STG (sent traffic
grapher) and RTG (receive traffic grapher) tools were used
The STG tool is used to send traffic and the RTG is used to
receive traffic. The STG can be used with several modes
like TCP, UDP and configuration which allows us to write a
script and translate the human conversation into a form that
the STG tool can read from the script to generate the traffic
as per the defined VoIP parameters for a human
conversation.
Figure. 1: Scenarios Design and details, VoIP(UDP) and non-VoIP(TCP)
profile summaries
The non-VoIP profile background traffic is simulated
using the STCP and RTCP traffic generation tools. Here a
simple TCP greedy traffic mode, where the tool establishes
numerous TCP connections between the two communicating
nodes and transmits TCP data. This traffic is generated to
simulate the background traffic. The test cases of VoIP only
and VoIP with non-VoIP traffic profiles are simulated in
three different scenarios as shown in Figure. 1. Each one of
the 26 nodes is configured with following traffic generation
tool commands. As an example, Node1 and Node 25
configuration commands are explained for profile 1 and
profile 2. All other nodes are configured the same way in all
scenarios.
Node 1 configuration for VoIP only profile.
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
Node 25 Configuration for VoIP only Profile:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
Node 1 configuration for VoIP and non-VoIP Profile:
stg -i spkrconfig1.cfg -p 4000 1.0.1.25
rtg -u -p 4000 -w pktlog1 -o thrlog1
rtcp -p 5000 -w rtcplog1
Node 25 Configuration for VoIP and non-VoIP Profile:
stg -i spkrconfig2.cfg -p 4000 1.0.1.1
rtg -u -p 4000 -w pktlog25 -o thrlog25
stcp -p 5000 1.0.1.1
No mobility, limited mobility and full mobility scenarios
are formed by 26 mesh nodes. In No mobility scenario all the
26 nodes are stationary and they don't have any movement.
Each node is involved in a VoIP conversation with another
node. So there are 13 mesh-node peers communicating to
each other, shown in Table 2.
Tx.
Sta
tus
No.
Pack
ets
Inter packet
delay in sec
Packet length in
bytes
Min
Ma
x
Av
g
Min
Ma
x
on: 500 0.01 0.05 70 60 80
off: 2
on: 1500 0.01 0.05 70 60 80
off: 19
on: 2250 0.01 0.05 70 60 80
off: 19
on: 3000 0.01 0.05 70 60 80
off: 34
on: 2250 0.01 0.05 70 60 80
off: 19
on: 1500 0.01 0.05 70 60 80
off: 19
on: 2250 0.01 0.05 70 60 80
off: 19
on: 3000 0.01 0.05 70 60 80
off: 35
on: 2250 0.01 0.05 70 60 80
off: 19
on: 250 0.01 0.05 70 60 80
off: 4
Table 1: Speaker 1 STG VoIP
Configuration Script using silence suppression (Off),Speaker2
configuration script is the same, except
the number of packets values are less.
75
Spkr 1
N 1
N 2
N 3
N 4
N 5
N 6
N 7
N 8
N 9
N 10
N 11
N 12
N 13
Spkr 2
N 25
N 15
N 26
N 14
N 22
N 21
N 18
N 16
N 17
N 24
N 20
N 19
N 23
Limited mobility scenario is designed and configured with
10 nodes moving at a walking speed of 1.3m/sec, while the
other 16 nodes are stationary. All moving nodes travel along
the pre-defined path and return back to their original
positions. The aim of this scenario is to discover the affects
of mobile and stationary nodes on the VoIP traffic. Full
mobility scenario is designed and configured to simulate all
the mesh nodes moving in a walking speed of 1.3m/sec,
shown in Figure 2. All nodes move to a pre-defined path
(gray lines) and come back to their original position.
V. RESULTS
Analyzing each one of the VoIP QoS factors, Figure.3
shows that delay in VoIP only profiles are the lowest,
regardless of the node mobility factor. VoIP traffic delay in
scenarios with background traffic is mostly higher than
200ms, only in a few nodes where the VoIP peers are only
one hop away, the delay is lower than 200ms.
Figure. 3: In all scenarios VoIP only profiles have less delay compared to
profiles with background traffic.
Jitter analysis (Figure. 4) shows that scenarios with VoIP
only profiles have lower jitter rates, while scenarios with
background profile have higher jitter rates. In all scenarios
the jitter limit of less than 100ms is not crossed.
Figure. 4: In all scenarios VoIP only profiles have lower jitter rate
compared to VoIP profiles with background traffic.
The packet loss analysis (Figure 5) shows that nodes
mobility increases packet loss. Even scenarios with VoIP
only profiles have packet loss rates above 5%. Scenarios with
background traffic have packet loss reaching up to 80% rate.
Only in a few nodes, where VoIP peers are one hop away,
does it fall below 5% rate.
Figure. 5: Nodes Mobility increases packet loss. All scenarios have lower
packet loss rate in VoIP only profiles.
Throughput analysis (Figure. 6) shows that
scenarios with VoIP only profile require 40-45kbps
bandwidth. In scenarios with background traffic, bandwidth
allocation and usage is still on the same range, but traffic
prioritization and use of priority queues are required, since
both types of traffics are using the normal queues.
Figure. 6: All scenarios, VoIP only profiles required 40-45 kbps
0
500
1000
1500
2000
2500
Del
ay
Del
ay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
Del
ay
Del
ay
Del
ay
De
lay
De
lay
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Del
ay in
ms
Nodes
Delay analysis of all scenarios and traffi profiles
No mobility UDP No mobility UDP+TCP
Limited mobility UDP Limited mobility UDP+TCP
Full mobility UDP Full mobility UDP+TCP
0
5
10
15
20
25
30
35
40
45
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
Jitt
er
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Jite
r in
ms
Nodes
Jitter Analysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
-10
0
10
20
30
40
50
60
70
80
90
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
Pack
et lo
ss
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Pac
ket l
oss
%
Nodes
Packet loss % Analsysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
-200
0
200
400
600
800
1000
1200
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
Th
rou
gh
pu
t
Thro
ugh
pu
t
N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14 N15 N16 N17 N18 N19 N20 N21 N22 N23 N24 N25 N26
Thro
ugh
pu
t in
kb
ps
Nodes
Throughput Analysis for all Scenarios and Traffic Profiles
No mobility UDP No mobility UDP+TCP Limited mobility UDP
Limited mobility UDP+TCP Full mobility UDP Full mobility UDP+TCP
Table 2: Speaker 1 & Speaker 2 VoIP peers information for all
scenarios. In total 13 VoIP peers are communicating.
Figure. 2: All 3
scenarios have similar screenshots, in no
mobility scenario all
nodes are stationary,
in limited mobility
scenario nodes: 2, 5,
8, 9,11, 13, 16, 21, 23 & 25 are mobile and
in full mobility
scenario all nodes are mobile.
76
VI. CONCLUSION AND FUTURE WORK
VoIP applications in WMNs, whether nodes are
stationary or mobile, can be successful if no background
traffic is mixed with VoIP traffic. VoIP implementation with
background traffic may not be successful if QoS is not
implemented among mesh nodes; Nodes mobility can result
more packet loss; If nodes mobility with a speed of 1.3m/sec
causes packet loss, then high node mobility can increase the
packet loss to an extend that would make the VoIP
implementation unusable; Jitter rate in all the three scenarios
didn't cross the acceptable VoIP jitter limit, therefore a jitter
buffer can very well solve the problem of the jitter in VoIP
implementations; If the VoIP enabled wireless mesh nodes
happen to be close to each other or only one hop away, the
VoIP conversation can run smoothly even if there is
background traffic generated or processed by the VoIP
enabled nodes; VoIP conversation requires a throughput of
an average 40-45 kbps; The mobile mesh nodes movement
direction has great significance on VoIP traffic quality. If a
mobile node is moving towards the direction of its
communicating node, the VoIP quality improves, if the mesh
node is moving against the direction of its communicating
node the VoIP quality degrades.
Recommendations for VoIP implementation over
WMNs are as follows: Until QoS standards are not supported
by WMNs, it is better to create a separate network for VoIP
applications, so that other traffic won't mix with VoIP traffic;
Proper routing protocol according to the nodes' mobility
model has to be selected; In WMNs design, nodes moving
path should be defined in such a way that it can move
towards its communicating nodes, where possible; If and
when possible mesh nodes mobility speed should b kept to
minimum.
Limitations of this research is as follows: Simulating
one mobility model; Running test cases in a simulator, not in
a real network; Time and hardware constrains in order to
simulate a large WMN of more than 100 nodes; Simulating
test cases using GoD routing protocol; Mesh nodes formation
by clients only; Usage of one type of VoIP profile;
Background traffic simulation using TCP greedy; VoIP
traffic parameterization considering the common G.729
codec.
Future work based on this research can be focused
on any of the following; Testing the same scenarios, but
using different WMN routing protocols and analyzing the
VoIP QoS factors; Modifying mesh nodes mobility speed to
a faster speed and study its affects on VoIP QoS factors;
Modifying mesh nodes movement path and direction and
then analyzing its affects on VoIP QoS factors; Increasing
the number of mesh nodes and studying its affects on VoIP
QoS factors; Changing the VoIP profile parameters and
characteristics according to other codec types and studying
its affects on VoIP QoS factors; Configuring the mesh nodes
to switch to ON and OFF states and then studying how the
WMN topology changes and how the VoIP QoS factors are
affected; Adding mesh access points and routers as fixed
devices and studying their affects on VoIP QoS.
Note: This is an unpublished draft paper.
REFERENCES
[1] Akunuri, K., Arora, R., & Guardiola, I., G. (2011). A study of
speed aware routing for mobile ad hoc networks. International
Journal of Interdisciplinary Telecommunications and
Networking, 3, 40-61.
[2] Anand, K., Samrat, G., Samir, R. D., & Suman, B. (2007).
VoIP on wireless meshes: Models, algorithms and evaluation.
INFOCOM 2007. 26th IEEE International Conference on
Computer Communications, 2036-2044.
[3] Cisco Systems. (2006). Voice over IP - per call bandwidth
consumption. http://www.cisco.com
[4] Dang, T. D., Sonkoly, B., & Molnár, S. (2004). Fractal
analysis and modeling of VoIP traffic. Telecommunications
Network Strategy and Planning Symposium. NETWORKS
2004, 11th International, 1-8.
[5] Divecha, B., Abraham, A., Grosan, C., & Sanyal, S. (2007).
Impact of node mobility on MANET routing protocols models.
SoftComputing.net, 1-10
[6] Dragos, N., Samrat, G., Kyungtae, K., & Rauf, I. (2007).
Performance of VoIP in a 802.11 WMN. Proc. INFOCOM
2006. 25th IEEE International Conference on Computer
Communications, Barcelona, Spain. 1-11
[7] Jian, L., Zhi, L., & Prasant, M. (2008). Adaptive per hop
differentiation for end-to-end delay assurance in multihop
wireless networks. Ad Hoc Networks Journal,
[8] Jun, J., & Sichitiu, M., L. (2008). MRP: Wireless mesh
networks routing protocol. Computer Communications
Butterworth-Heinemann, 31(7), 1413-1435
[9] Kaur-Kehal, R., & Sengupta, J. (2011). A comprehensive
review on improving QoS for VoIP in wireless mesh networks.
Journal of Global Research in Computer Science, 2, 32-33.
[10] Kim, H., Yun, S., & Lee, H. (2007). Boosting VoIP capacity of
wireless mesh networks through lazy frame aggregation.
IEICE Trans. Commun., E90–B, 5, 1283-1285.
[11] Kim, K., & Shin, K., G. (2006). On accurate measurement of
link quality in Multihop wireless mesh networks. Proc.
MobiCom '06 Proceedings of the 12th Annual International
Conference on Mobile Computing and Networking, 38-49.
[12] Liese, S., Wu, D., & Mohapatra, P. (2006). Experimental
characterization of an 802.11b wireless mesh network. Proc.
IWCMC '06 Proceedings of the 2006 International Conference
on Wireless Communications and Mobile Computing, 587-592.
[13] Mlinarsky, F. (2006).The challenges and importance of testing
mesh networks prior to deployment. Rf Design, 29(6),16-23.
[14] Reddy, B., T., John, J., P., & Murthy, S. R., C. (2006).
Providing MAC QoS for multimedia traffic in 802.11e based
multi-hop ad hoc wireless networks. Computer Networks, 154-
176.
[15] Shao, H. (2004). Multimedia QoS support specified in various
wireless network standards. IEEE MultiMedia, 11(4), 75-77.
[16] Waharte, S., Boutaba, R., Iraqi, Y., & Ishibashi, B. (2006).
Routing protocols in wireless mesh networks: Challenges and
design considerations. Multimed Tools Appl, (29), 285-303.
[17] Wang, S., Chou, C., & Lin, C. (2010). The GUI user manual
for the NCTUns 6.0 network simulator and emulator Network
and System Laboratory, Department of Computer Science,
National Chiao Tung University, Taiwan. http://nsl10.csie.
nctu.edu.tw
[18] Wang, S., & Lin, Y. (2005). NCTUns network simulation and
emulation for wireless resource management. Wireless
Communications and Mobile Computing, 5, 899-916.
[19] Wang, X., Chen, S., & Jajodia, S. (2005). Tracking anonymous
peer to peer VoIP calls on the internet. Proc. Computers and
Communications Security, 81-91.
[20] Wu, C., Chen, K., Chang, Y., & Lei, C. (2008). Detecting
VoIP traffic based on human conversation patterns. Systems
and Applications of IP Telecommunications, 1-8