VoIP using Wireless Mesh Infrastructure

By Don Moskaluk, January 4, 2007

With the emergence of new applications on mesh networks, it is becoming increasingly important for providers to accurately predict the impact of new application rollouts. In Locustworld it is easy to allocate bandwidth to applications and let the applications adapt to the exploding nature of traffic flows through timeout and retransmission functions. However, Voice over IP (VoIP) applications are more susceptible to changes in the transmission characteristics of data networks. It is imperative to understand the traffic characteristics of the network before deployment of new VoIP applications to ensure successful implementations.

VoIP is susceptible to wireless network behaviors, referred to as delay, jitter and packet loss, which can degrade the voice application to the point of being unacceptable to the average user.

Delay is the time taken from point-to-point in a network. Delay can be measured in either one-way or round-trip delay. However, most open source tools only provide a round-trip measurement. To get a general measurement of one-way delay, major router manufacturers such as CISCO suggest to measure round-trip delay and divide the result by two. As a result of the measurement, VoIP typically tolerates delays up to 150 ms in a single direction before the quality of the call is unacceptable.

Jitter is the variation in delay over time from point-to-point. If the delay of transmissions varies too widely in a VoIP call, the call quality is greatly degraded. The amount of jitter tolerable on the network is affected by the depth of the jitter buffer on the network equipment in the voice path. The more jitter buffer available, the more the network can reduce the effects of jitter. Most VOIP endpoint devices have jitter buffers to compensate for network jitter. Quoting from Cisco: Jitter buffers (used to compensate for varying delay) further add to the end-to-end delay, and are usually only effective on delay variations less than 100 ms. Jitter must therefore be minimized. The acceptable level of jitter in a network should be less than 2ms.

Packet loss is losing packets along the data path, which severely degrades the voice application. VOIP is not tolerant of packet loss. Even 1% packet loss can "significantly degrade" a VOIP call using a G.711 codec and other more compressing codecs can tolerate even less packet loss. Cisco says: The default G.729 codec requires packet loss far less than 1 percent to avoid audible errors. Ideally, there should be no packet loss for VoIP. Most networks specify maximum packet loss for an example Qwest 0.5% maximum packet loss.

Prior to deploying VoIP applications, it is important to assess the delay, jitter, and packet loss on the data network in order to determine if the voice application works. The delay, jitter, and packet loss measurements can then aid in the correct design and configuration of traffic prioritization, as well as buffering parameters in the wireless mesh network equipment.

My recent focus and interest has been improving and providing carrier class wireless network. This is partly motivated by a requirement for an Internet Protocol Quality of Service (IP QoS) solution to allow us to converge our video, voice and data networks with in the Mesh Network.

The problem is a lack of understand of what kinds of metrics a network operator can use to improve QoS, what should be measured, and what would drive the right kind of performance matrix that would drive the technical, and operational changes that would make the network better.

iperf is a measurement tool developed by NLANR. It's been used very extensively in the research community for projects like Web100 and the Abilene network. iperf can measure node-to-node throughput, packet loss, jitter and latency. It has a wide variety of options to measure all sorts of network characteristics. It runs on Linux, Solaris, Windows, MacOSX and any other platform that can compile the source-code. iperf (coupled with MRTG or Cricket for graphing) looks like a great possibility to actively measure the performance of different kinds of traffic across the network, and because it is portable and inexpensive, it could easily be deployed pervasively throughout the network.

Any wireless mesh network provider will require this monitoring to provide a high Quality of Service to achieve a carrier class mesh. The key issue for a carrier class mesh is to have application work as well as wired routing.  Wireless mesh networks must prioritize telephony traffic because, voice data must be transmitted in real time and other data traffic with which it shares the Internet can be delayed. When the voice quality degrades and latency becomes a problem then standard approaches to traffic shaping is required for QoS and Internet telephony.

The QoS routing procedure can inform the source of the bandwidth and quality of service available to any destination in the wireless mesh network. This knowledge enables the establishment of QoS connections within the wireless mesh network and the efficient support of real time, multimedia traffic. In addition, it enables more effective call acceptance control. In the case of a wired interconnection, QoS information permits one to extend the wired virtual circuit service to the wireless mesh network, with possible renegotiation of QoS parameters at the gateway or uplink node.

Quality of Service is the capability of a network to provide better service to selected network traffic.  QoS support is available in a variety of networking equipment for example MeshAP.  MeshAP using Wiana tools can let you manage the end-to-end efficiency of your voice traffic by using bandwidth shaping.  However, the Pro version of Locustworld has key settings for additional QoS specifications. Locustworld pro accomplishes this by prioritizing packets based on traffic type, enabling access points to schedule resources based on transmission rates and latencies, and therefore improving bandwidth efficiency.

The primary goal of QoS is to provide priority including dedicated bandwidth, controlled jitter and latency, and improved loss packets.  QoS provides priority service to selected traffic to optimize the use of available bandwidth, control jitter and latency and improve loss characteristics.  QoS tools provide control over congestion management, queue management, traffic shaping and policing, and link efficiency.  This makes it easier for telephony applications to co-exist on a network.  The ideal to optimize QoS for one data flow does not make other data flows fail.  The issue is how to guarantee that packet traffic for a voice or other media connection will not be delayed or dropped due to  interference from other lower priority traffic.

As a result, to provide a VoIP application in the wireless mesh a Carrier Class installation is required.   To optimize VoIP application in wireless mesh the following should be examined:

The solution to provide a QoS service for VoIP using wireless mesh can be achieved by using different configurations and providing a methodology to monitor and deploy VoIP within a mesh.  To illustrate this I have provided a scenario in which Bandwidth reservation and shaping can be selected for VoIP as well as prioritization.  Network traffic Monitoring and tuning can then be added to application services within the wireless mesh.  This will lead to a new deployment strategy of VoIP providers in using application services.

Providing application service near or in the mesh network has been a challenge but not impossible.  With various tools in WIANA to host an application near or wired to the mesh cloud can provide some prioritization in VoIP applications.  For example when signing up with a VoIP provider outside the Wireless Operator the VoIP call can have large latency due to the nature of Mesh Network deployment.  Because of topology and deployment of the mesh nodes, an operator may not have the facilities to move the mesh node into optimal positions.

  To alleviate this problem moving the application server near to or into the mesh cloud could help the performance of the VoIP Call.  As illustrated below:

However, this creates a new problem within the wireless mesh, having all traffic funnel through a single mesh Uplink node.  In WIANA there is a provision wire SIP call through a dedicated Uplink.  This improves the latency and ensures that the SIP calls can transverse beyond the mesh cloud.  The problem occurs when there are many uplink nodes to a single mesh cloud as illustrate below:

The VoIP Provider can only have access through a single Uplink node.  The rest of the nodes would not be used for the VoIP traffic.  This then defeats the purpose of having VoIP coming through a single Uplink node.    To minimize the effect on MeshAP, uplink nodes must be able to handle all available traffic.  To prioritize VoIP traffic through a single Uplink node a VoIP application must be within the Wireless Mesh Cloud as indicated below:

As illustrated above the VoIP application Server is linked to a MeshAP (node), the node can be prioritized to the MeshAP that has the link to the VoIP Provider.  The MeshAP with VoIP Application Server will be dedicated to only VoIP traffic and the traffic shaping utility can ensure the traffic for VoIP goes only through a one dedicated Gateway.  The rest of the traffic could be shaped per user and would have sufficient bandwidth for all other applications.  This would relive the bottleneck and ensure prioritization for VoIP as illustrated below:

Traffic normally in the mesh has a higher bandwidth and can be shaped to ensure minimum through puts.  The Green lines indicate a mix of VoIP, multimedia and data traffic.  The VoIP Application provider can then have a dedicated node for a large pipeline (illustrated by the yellow lines) and ensures that only VoIP traffic is sent to the VoIP provider. 

The VoIP application Server within the Mesh Cloud can then have monitoring tools added to the application to ensure QoS services.  A laptop with similar software could be used to test each node for QoS services.  In addition the VoIP Provider should also have similar QoS monitoring software.  Although this solution is unique, it starts providing the necessary framework for a carrier class network.  This also illustrates a new type of uplink node based on bandwidth shaping, application, monitoring, and prioritization (BAMP.)

The key to BAMP uplink node will ensure that only traffic prioritized for the application server with in the mesh cloud will be used.  The problem is with the wired link between the MeshAP and VoIP Application Server.  Wired connection to the MeshAP may contain other data packets and use the priority of others for the use of VoIP such updating the server or applications.  The VoIP application Server is actually similar to the VoIP wired provider in that the service is not connected to the outside world.  The placement of the Application Server is critically important.  This will need to be determined by the QoS.

Although the above scenario only shows application services in a single radio MeshAP, it can be further illustrated with dual radio cards in the MeshAP.  When one looks at the topology of a wireless mesh network it shows the complication of having multiple radio cards and multiple bandwidths. 

Multi radio cards lead to a scenario of having a centralized bandwidth or centralized uplink node that is distributed in a near star pattern to other mesh clouds, please see Metropolitan nodes topology.   However there are other uses of having dual radio cards.  They also provide priority for applications.  One band could be used for user traffic and the other band or frequency for applications.  Nevertheless how you prioritize the traffic would be the same as illustrated in the above diagrams.

In Locustworld software modules there are two distinct VoIP applications:

Clustering SIP Proxy is LocustWorld’s mesh it routes SIP streams around from node to node using the clustering SIP proxy module, which is based on siproxd. Siproxd is a proxy masquerading daemon for the SIP protocol. It handles registrations of SIP clients on a private IP network and performs rewriting of the SIP message bodies to make SIP connections work via a masquerading firewall (NAT). It allows SIP software clients or SIP hardware clients to work behind an IP masquerading firewall or NAT router.

Asterisk® is a complete IP PBX (private branch exchange), in Locustworld Asterisk software the module is a development version of asterisk open source software. It can be used in various ways to perform useful voice over ip functions, but needs some additional configuration to become more flexible. 

Both Locustworld VoIP services are unique and do not work together.  You can either run the Clustering SIP Proxy or Asterisk PBX but not both. Further limitation to the Asterisk module is that it is restricted to a version and there is no ability to add any functionality or even upgrade the module.  The module has been scaled down in a bare minimum configuration.  This has been done to fit on a 64 Meg flash card. Nevertheless, both software modules do provide basic functionality that can be used in any VoIP deployment.

The latest version of Asterisk open source is very robust and has many add on features.  It however is very cumbersome to install on a new installation of either Linux or Windows.  Locustworld does provide a development version of its OS however to combine a full feature rich OS with both Locustworld and Asterisk would be very difficult to duplicate. 

Locustworld installation and deployment is very simple and elegant.  To maintain a MeshAP and configure it can easily be done through WIANA.  Locustworld is feature rich and is easy to install and deploy once one obtains the proper methodology. 

There is a very elegant version of related software that configures Asterisk, freePBX, SugarCRM, LAMP, and a host of utilities on a CentOS Linux distribution, it is called Trixbox.  Trixbox distribution like Locustworld can be easily downloaded, put on CD and installed on a PC.  Within about a hour the software is fully configured and only requires some quick configuration to provide a full VoIP solution.  Trixbox functionality can provide a bridge between Plain Old Telephone Systems POTS and VoIP.  Trixbox  also provides an integrated CRM package with full feature telephony.  Trixbox can be configured to handle a single phone line for a home user, several lines for a small office, or several T1s for a million minute a month call center.  Trixbox features include:

Along with the standard Business telephone feature, voice mail, caller ID, call forwarding, call routing, menus, music on hold, voice mail forwarding to email, etc.   The variety of codec and the amount of various hardware and software is overwhelming.  However the robust tools for management and administration are excellent.  When managing many users that require backups Trixbox is excellent as an Application Service.  Locustworld has an excellent centralized management system with WIANA; however, with Trixbox there are no centralized tools and requires system administration. Trixbox can be linked together with other Trixboxes, Asterisks servers, or even Locustworld to provide a complete telephone solution for any Service Provider.  

With Trixbox one can easily provide a modern day telephony solution.  By adding these services to Locustworld one will not only provide additional service for Wireless Mesh Network but also provide mobility using the Trixbox features.  This next generation service can be accomplished but requires QoS specification and a new methodology.

Locustworld methodology provides Wireless mesh through various uplink nodes.  Services other than authentication are provided via Internet.  No applications are provided by other servers or integrated services.  With Trixbox you have a bridge between POTS and the internet plus you have various servers to maintain.  As a result you will require a different architecture to work within the Locustworld topology.

As shown below the Trixbox works between a router and the Uplink MeshAP node.  It provides access to Analogue DID, VoIP Trunk and DID Providers.  Since Trixbox is web based it can easily be integrated with the Locustworld architecture.  Trixbox can be integrated together having various branches in other locations throughout the internet.   Trixbox can also be added with Mesh Cloud by either wiring to a MeshAP as a downlink node or client when adding a prism 2.5 radio card.  

New devices such as IP Telephones, Wi-Fi PDA, Wi-Fi portable Phone, Laptops and of course, PC with soft phone can access the Trixbox.  This provides not only mobility for Trixbox users but provides other functionality such CRM.  These Wi-Fi appliances can access the Trixbox services similar to Cellular technology; however, the transfer between MeshAP can be at times choppy.   This is because Locustworld uses IPv4 and the transfer of the IP address takes time to release and renew.  In the future the IPv6 will improve the mobility within the Mesh.

The above diagram illustrates how Trixbox and Asterisk providers can start adding the benefit of adding connectivity to the service via satellite, internet and wireless mesh.  For a Locustworld provider additional telephone service can be provided.  Locustworld SIP Clustering or Asterisk development telephone services can be added to existing wireless LANs.  Extending Trixbox to the wireless community provides a full feature reach system, which will benefit from 11 MBPS connection using a 2.4 Ghz Wi-Fi Radio Card.

Wireless Mesh Network provides bandwidth to a given area.  When more bandwidth is required different equipment and topology is required.  By adding a second radio card to a MeshAP additional bandwidth can be added.  This bandwidth and the placement can provide any Wireless ISP the appropriate bandwidth to maintain a high quality of service.