The Village Telco project: a reliable and practical wireless mesh telephony infrastructure

VoIP (Voice over IP) over mesh networks could be a potential solution to the high cost of making phone calls in most parts of Africa. The Village Telco (VT) is an easy to use and scalable VoIP over meshed WLAN (Wireless Local Area Network) telephone infrastructure. It uses a mesh network of mesh potatoes to form a peer-to-peer network to relay telephone calls without landlines or cell phone towers. This paper discusses the Village Telco infrastructure, how it addresses the numerous difficulties associated with wireless mesh networks, and its efficient deployment for VoIP services in some communities around the globe. The paper also presents the architecture and functions of a mesh potato and a novel combined analog telephone adapter (ATA) and WiFi access point that routes calls. Lastly, the paper presents the results of preliminary tests that have been conducted on a mesh potato. The preliminary results indicate very good performance and user acceptance of the mesh potatoes. The results proved that the infrastructure is deployable in severe and under-resourced environments as a means to make cheap phone calls and render Internet and IP-based services. As a result, the VT project contributes to bridging the digital divide in developing areas.


Introduction
The cost of making a call and sending an SMS in most parts of Africa is extremely high compared to income. a Soft phones running on PDAs, WiFi-enabled VoIP handsets, and cell phones with WiFi capabilities already exist and as VoIP over WLAN becomes widespread, it is possible that a large proportion of cell phone or WiFi handset owners will migrate to using VoIP over WLAN, due to the prospect of cheaper or even free calls. However, this requires the availability of a standardized and open architecture to facilitate seamless interoperation of these devices. The Village Telco has realized one possible basis for an infrastructure in the process of developing the mesh potato.
The Village Telco (VT) is an easy to use, scalable, standards-based, and DIY (Do it Yourself) telephone company toolkit. It is a local and wireless infrastructure that can provide a local telephone network for personal use and make a sustainable business for interested parties. By paying or charging a nominal fee, calls could be made to the PSTN (Public Switched Telephone Network), and cellular networks, via VoIP trunks.
Wireless nodes form a wireless mesh network (WMN) with nearby wireless access points to provide wireless links [1,2]. Although the primary purpose of the infrastructure is to make cheap voice calls, users can also exploit the IP-based architecture to access the Internet. In addition, the WMN can provide network capacity for community activities, such as content distribution, education, health care, games, file sharing, peer-to-peer applications, and services and resource sharing [3].
The VT project like some other WMN solutions uses multiple transmission bands. The 802.11a (5 Ghz band) is for the backbone and the 802.11b/g/n (2.4 GHz band) is for the access links [4].
Due to the changing wireless conditions and channel interference, delay and loss characteristics can vary over time along a multi-hop path between a source and destination of a voice call [5]. In addition, packet losses and delay due to interference in a multiple-hop mesh network with limited capacity can significantly degrade the end-to-end VoIP call quality. As a result, the design of a quality WMN could be difficult. This paper discusses the Village Telco infrastructure, how it manages the above difficulties, the functions of a mesh potato (MP), and its efficient deployment for VoIP services in some communities around the world. Results show that by taking into consideration, packet aggregation and header compression, the number of supported VoIP calls in a multi-hop network could increase by 2-3 times.
The paper is arranged as follows: Section 2 presents the background and related work, Section 3 presents the Village Telco architecture, Section 4 discusses the design considerations and implementation, Section 5 presents the deployment and preliminary results. Lastly, the conclusion is presented in Section 6.

Background and related work
Routing protocols used by WMN solutions vary from one product to the other. Cisco solutions use a proprietary routing protocol called Adaptive Wireless Path (AWP) b and Nortel solutions use the traditional open shortest path first (OSPF) wired routing protocol [6]. VMesh uses Optimized Link State Routing (OLSR) that is a standard proactive routing protocol. RoofNet uses a hybrid approach called Srcr, which combines link state and DSR style on demand querying. Other protocols used in WMN solutions include the Ad Hoc On-Demand Distance Vector (AODV) [7] and Hazy Sighted Link State (HSLS) routing protocols [4].
Open source software programs used to manage user authentication for multiple wireless hot spots include NoCatAuth [8] and wifidog. c Groups, such as freifunk, d CUWIN and Open Mesh, e have focused on developing open source software that enables meshing and examples are CUWiNware, DD-WRT, and OpenWRT.
Although most WMN projects can be classified into community and commercial projects, intra-campus wireless networks now exist in several universities and research centers [9]. The wireless networks are used for ubiquitous communication. Examples are RoofNet at MIT, VMesh in Greece, Mesh-Net at UCSB, and CUWIN at Urbana [4,10]. Some of the commercial solutions already in the market are FON, Meraki, Nortel, and Cisco WMN solutions. They all provide specific hardware for use in sharing broadband. FON, however, has a different business approach [11]. Its objective is to develop community-centric alternatives to existing broadband infrastructure. FON does not only sell equipment to create hotspots, but also provides an infrastructure to manage authentication, billing, and aggregate information on hot spot locations. As a result, they facilitate the creation of many hots pots in many locations and their members enjoy global roaming. WMN solutions are prone to problems, such as bandwidth degradation, radio interference, and network latency [12]. Consequently, the inherent multi-hop mesh networks only provide limited scalability and are deemed unsuitable for large-scale network deployments. Challenges encountered during deployment include ad hoc partitioning, inconsistent transmission power, link quality variability, density, and DNS route maintenance.

The Village Telco architecture
The Village Telco is a mesh network of mesh potatoes (MPs), where adjacent MPs automatically form a peerto-peer network and relay telephone calls without landlines or cell phone towers. An (MP) is an 802.11b/g mesh router with a single FXS (Foreign Exchange Station) port that accepts an ordinary two-wire telephone. The MP hardware and software architectures are open. Figure 1 shows the network architecture of the VT. The primary components are the MPs, and the Ubiquiti Nanostations flashed with a VT boot image.
All mesh nodes communicate on a single WiFi channel. An MP can operate its WiFi interface in two modes simultaneously: (1) ad hoc mode that interacts with nearby MPs and (2) infrastructure mode that either acts as a client to obtain Internet access or as an access point to allow ordinary WiFi devices to obtain network access. The use of both modes makes it possible to design the system without any specialized software on WiFi-enabled cell phones. An ad hoc network is the cooperative engagement of a collection of mobile nodes without the intervention of any centralized access point or existing infrastructure [7,13]. Use of ad hoc mode only would need client device configuration with appropriate software, which is discussed in the next section.
A telephone box is connected to an MP, which forms a mesh network with other MPs. An MP can also connect to a nanostation that links mesh islands to one another. Internet connectivity can be leveraged to connect a mesh and its telephones to the global PSTN. In Figure 2 is a mesh of MPs connected to a traditional fixed telephone service. It forms a local isolated network and is also connected to the Internet. Nanostations, MPs, or similar low-cost hardware may be used to extend the range of the mesh network or to connect it to the Internet. Once connected to the Internet, it is possible to route calls between the mesh and the global PSTN.
Nanostations are repeaters, which are typically used to bridge two or more mesh clouds to form a large network. In peer-to-peer networking, a supernode is any node that acts as a network relayer, which handles data flow and connections for other users. Hence, a nanostation functions as a supernode. Ideally, a supernode would contain three nanostations mounted on a single

Design considerations and implementation
This section presents the hardware design, software design, and choice technologies. The hardware is an open hardware and the software packages used are FLOSS (Free/Libre/Open Source Software) packages.

Hardware design
The device primarily consists of an Atheros System-ona-Chip (SoC) that acts as the hub for memory, network, and analog telephone connections. Figure 2 shows the hardware architecture. The schematics are available online. f The MP modules include the FXS port, glue logic, Ethernet, 802.11b/g wifi, 32 M SDRAM, 8 M SPI, and the Atheros SoC. The FXS port provides an interface for the analog phone, and the Ethernet module provides interface for IP connectivity, which could be used for IP phones or to provide Internet connection. The glue logic is used to connect the FXS port to the Atheros chip set. The SPI (Serial Peripheral Interface) flash provides synchronous serial data link with fullduplex capability to implement an efficient and highspeed data stream. While the 802.11b/g WiFi makes the MPs connect to one another, the SDRAM provides the needed high computing capacity. The Atheros Systemon-a-Chip (SoC) is the Atheros AR2317 SoC. It is a very low-cost router chip that combines an MIPS processor running at 180 MHz with 802.11b/g WiFi. It has builtin interfaces for LEDs, SDRAM, and serial flash. Another benefit of this chipset is that it is well supported by OpenWRT and Mad-WiFi, which makes it relatively easy to port the necessary software.
OpenWRT is a Linux distribution for embedded devices and is particularly well suited for WiFi routers. MadWiFi is a WLAN driver firmware. The developed FXS hardware, drivers, and other firmware are generic and could be ported to other routers. It is however recommended that in very high volume production, the FXS chip set functionality should be integrated into the SoC. Figure 3 shows the version 1.1 of the MP motherboard and its casing, while Figure 4 shows the version 1.3 of the motherboard and its casing. The N-type antenna connector can be seen on the MP in The power, Ethernet, and FXS ports are designed with developing world conditions in mind. As a result, it offers some resistance to electrostatic discharge, poor input power quality, and accidental abuse. One of the design goals was to make the MPs survive 240 V mains when it is connected to any of an MP's input ports. This event might be expected in the developing world due to lack of user education, unlabeled, and unterminated power  The Ubiquiti Nanostation g was preferred to the Linksys WRT54Gx as a supernode. h The reason is that the Ubiquiti Nanostation, which has a ruggedized case, is specifically designed for outdoors and is more powerful than the Linksys routers. In addition, the Ubiquiti Nanostation could run OpenWRT, thereby making it possible to compile and run the core BATMAN software that manages the VT mesh network on it.
Several of the design considerations for the MPs are discussed in more detail below. They include antenna selection and its connector, power consumption, power range and reversed DC mains, and high AC voltage supply.

Antenna and its connector
There exists various coaxial RF connectors suitable for attaching an antenna. They include the N-Type, SMA, SMB, and SMC connectors. The N-Type antenna connector was however preferred to the R-SMA antenna (Reverse Sub-Miniature version A), which was considered earlier in the design process. Experience from various deployments showed that it is easier to break the R-SMA sockets. Hence, the N-Type antenna connector was used because it is more rugged. In addition, the N-Type connectors large diameter is easier to handle and its connection is simple. These design considerations were effected in the version 1.3 of the hardware in which the antenna is printed on the circuit board.

Power consumption
The MP operates at a 3.3 V DC rail and an unregulated 12 V DC rail for the FXS (phone) interface. Hence, the MP needs a DC voltage conversion unit on board. Most power consumed by the MP are drawn internally from the stabilized 3.3 V rail. The MP's voltage conversion unit therefore takes its share in the overall efficiency of the MP. Measurements have shown that the DC converter efficiency from the DC input socket to the internal 3.3 V rail is typically 86.6%. This is a good efficiency measurement considering the losses at the input section, which include the resistance losses introduced by the fuse and other components. The MP efficiency outperforms other Atheros AR2317based WiFi design and other DC converter chips, such as the Anachip AP1509.

Power tolerance
The custom design of the MP has allowed the inclusion of built-in circuit protection unlike other Atheros-based WIFI systems. Technically, inexperienced people with poor infrastructure greatly increase the risk of mistakes with power and connectors; so, one of the design goals was to design the MPs as robust as possible. The MPs have been designed to survive a reversed DC or mains AC to any pin of the Ethernet port, the FXS port, the DC socket, or the antenna socket. In addition, the MPs have a DC converter with a wide input voltage range of approximately 9-35 V so that a user can power it with a large variety of unstabilized power supplies. These capabilities help to make an MP robust for use in a variety of hostile settings.

Software design
The MP runs BATMAN (Better Approach To Mobile Ad hoc Networking) [14] mesh routing software, Asterisk, h Speex, j GSM voice codecs, and OSLEC k acoustic echo canceler. It is based on Atheros SoC hardware, thereby allowing the use of the MadWiFi open source WLAN driver. BATMAN was used because it has superior performance to various other mesh routing algorithms [14]. It also offers greater stability that is a desirable characteristic for a telephone network. The Speex and GSM codecs were used instead of the proprietary g729. Similarly, the OSLEC echo canceler was used instead of a proprietary echo canceler.
The MP includes a network management application called Afrimesh. Afrimesh makes it easy to create an IP network and is built on top of the BATMAN project to provide a simple management dashboard. The dashboard enables network operators to create and sustain a resilient communications network. Afrimesh is a web application that provides node/client management, network maps maintenance, network monitoring, and bandwidth management. It seamlessly integrates with the LUCI project, l which is a web interface for embedded devices that are running the OpenWRT m Kamikaze firmware. The integration provides a common interface for the MP configuration and the mesh network management. Afrimesh uses the Google maps or OpenStreetMap n to display its network maps with interconnected MP nodes ( Figure 5).
OpenStreetMap is a collaborative project to create a free editable map of the world. MPs and links between them are overlayed upon the Open-StreetMap display. Color is used to provide a simple means for quickly assessing the condition of the mesh network. Such universal use of open source software ensures that an MP can be produced as cheaply as possible and without any patent or intellectual property obligations. This is an important consideration given that the device is targeted at developing communities where price sensitivity will be significant. It also greatly reduces the likelihood of holdup by intellectual property holders in the event that the project was ever viewed as undesirably by any commercial concern.

Software technologies
One of the goals of the VT project is to enable local entrepreneurs to operate profitable micro-telco and micro-ISP enterprisers using the VT hardware. Thus, consideration has been given to billing and accounting software that would run on a separate Linuxbased computer. This inherent complexity in automatic billing systems has emerged as one of the difficult aspects of the project. Current approach involves modifying the A2billing°open source billing platform.
A2billing is a LAMP (Linux Apache MYSQL and PHP) application that sits on top of Asterisk, which bills and manages VoIP calls. A2billing takes advantage of the Asterisk Manager Interface (AMI) and Asterisk Gateway Interface (AGI) to deal with the call logic. A2Billing is a three-tier architecture package. It has an installation wizard and a simplified management interface for administrators, agents, and clients. The Village Telco project has extended A2Billing in two ways, namely providing a simplified management interface and extending A2Billing to support the Village Telco billing API. The installation wizard is based on the MVC (Model-View-Controller) framework using Cake PHP. SOAP (Simple Object Access Protocol) is used as the transport mechanism between the wizard and A2Billing. A2Billing has also been extended to support the VT billing API by implementing a web service that interacts with the A2Billing internal logic. The web service presents an API that hides the complex SQL back office logic.
MPs perform an internal routing, when a call is made. The interaction of the MPs is based on IP (Internet Protocol). The MPs can have connections across the mesh to other MPs (as shown in Figure 1), to other wireless devices, to other wired VoIP phones and to the Public Switched Telephone Network (PSTN), with the aid of the built-in Session Initiation Protocol (SIP) server called Asterisk. In this work, Asterisk SIP server and Private Branch eXchange (PBX) are used for supporting SIP phones and routing the VoIP calls to the PSTN.
Another fundamental design goal in this work is ensuring client-side transparency. The client mobile stations are unaware of the mesh networking backbone. They view the network as a conventional WLAN spread out over an extended geographic area. Thus, the clients still associate with an AP (Access Point) using a traditional association mechanism in WLANs. When a client moves and re-associates with a different AP, a layer-2 handoff event occurs that in turn triggers appropriate routing updates in the mesh network backbone. However, the IP of the MP remains unchanged since an MP is reached by dialing the last octet of its IP. The IP address is also bound to a phone number, which is human-friendly and the standard practice.

Deployment and preliminary results
This section presents experiences at communities in Cape Town, South Africa and Adelaide, Australia, where the VT was deployed. It also reports some of the experimental results that now make the MP specifications. Lastly, some of the research challenges and lessons learned in this project are discussed.

VT deployment
The testbed was spread over a community in Cape Town called the Bo-kaap Community. p It is a multi-cultural area close to Signal Hill. The inhabitants of Bo-Kaap are proud of their rich cultural heritage. They were mostly descendants of slaves which were imported by the Dutch during the eighteenth century. Two nanostations and sixteen MPs were deployed at Bo-kaap. They were installed in various homes with each MP within the line-of-sight range required to communicate with a nanostation or another MP.
In the current deployment, the mesh is a multi-hop extension of the regular AP (access point) infrastructure. It is useful to use the concept of a layer-2 switch to see the entire mesh as a single element that switches packets between its ports. A port can be defined as a mesh node that has at least two interfaces: one in an ad hoc mode for the back haul in the mesh and the other in an infrastructure mode to connect to clients.
This infrastructure can support a variety of clients, such as VoIP wireless phones, soft phones running on laptops and handheld devices. However, for this project, only MPs with telephone handsets connected to them were installed at the various homes.
The wireless interfaces in the MPs were configured to run at the fixed rate of 2 Mb/s for providing quality calls over the maximum range. In addition, the nanostations were configured with 50 Mb/s uplink, which helped in communicating to other VOIP phones and linking to the PSTN trunk. To evaluate the performance, traffic was locally generated at the nodes. In addition, some of the experiments were performed using the ns-2 simulator with 11 Mb/s uplink and downlink.
The Village Telco infrastructure has also been deployed in Dili in Timor Leste, suburbs of Adelaide area in South Australia and the Australian Outback. The distances between nodes (MPs) are increased or reduced by interference and local conditions [15,16]. Interference necessitated the use of nanostations to punch through the interference for even quite short links, often substantially less than 500 m. This is due to the omni-directional antennas being able to receive interfering signals.
In contrast, recent tests demonstrated flawless call quality between two pairs separated by 2.1 km and extending into Gulf St. Vincent in Adelaide, South Australia. q Similar robust performance was experienced by the serval project's field testing of MPs and compatible equipment in the Australian Outback. r Several calls were placed between MPs and smart phones over ranges of several 100 m without difficulty due to the low noise floor of the remote location combined with open terrain. The MPs and other equipments in the test were operated entirely from batteries and solar panels, thereby demonstrating the ability of the Village Telco paradigm to operate in areas devoid of traditional infrastructure. 11 V LiPo battery packs were directly coupled to MPs with no need for an external voltage regulation circuitry. The tolerance of a wide range of DC input voltages made the exercise painless.

Antenna impedance
The goal was to achieve approximately 50 ohms impedance in order to ensure that the maximum amount of power is transferred from an MP transmitter to the antenna. This can only be determined using SWR (Standing Wave Ratio). SWR is the ratio of the amplitude of a partial standing wave at an antinode (maximum) to the amplitude at an adjacent node (minimum). A standing wave ratio (SWR) bridge can be used to measure the SWR. In this case, a version of the bridge designed by Erwin Gijzen, s which comprised of a radio Ham and WiFi experimenter, was used. The SWR head was constructed, and the DC voltage from the bridge was measured using a multimeter. The bridge compares the impedance of the antennas to a known 50 ohms impedance. If they are equal, then the DC output from the bridge would be 0 V. Various degrees of mismatch gave different output voltages. Table 1 presents the various output voltages with different antenna types.
The antennas that indicated good results were the 50 ohms dummy, the 17 and 20 mm mono-poles, the off the shelf router antennas (which have sleeve dipole construction internally), and the wire antennas. The PCB dipole and PCB bi-quad antennas presented high SWR bridge outputs. That is, their impedances were not close to the reference 50 ohms.

The antenna gain
An 8 dBi Superpass was used as a reference. The signals from the Superpass were measured, and the results were saved on a screen as signal A. The test antennas in Section 5.2 were also used and their antenna gains were calculated based on the known Superpass gain. To obtain valid results, each antenna was moved around by hand until a peak was found. These tests were repeated several times in a day. While the absolute levels would change between 1 and 2 dB, the relative levels were always similar. Table 2 shows the antennas in order of their gains. The measurements have a tolerance of +/-1 dB and the RF level is the peak of the 802.11b signal on the spectrum analyzer.
The location, where peak received signal was found, was quite sharp. This may have been due to lobes in the signal from the nanostation or multipath interference. Several commercial router antennas were tested, 15 dB grid and commercial router antennas inclusive. They all measured about the same. The results from the control antennas (15 dB grid, 8 dB Superpass and nominal 2 dB sleeve dipole commercial router antennas) were consistent with the expected values. The PCB dipole was not being actively considered, as there were several other antenna candidates that perform just as well at 2 dBi. The impedance match and gain results from the PCB bi-quad were poor, which suggested the antenna is not resonant at 2.4 GHz. In contrast, the wire bi-quad performance with a reflector was remarkable, nearly as good as the grid antenna that is a much larger antenna.
The wire antennas are attractive due to their performance and simplicity. They are easy to make and tamper proof. One small problem with the dual loop biquad wire antennas is a feed arrangement-a small piece of coax needed to reach the central feed point. The antenna wire should not be directly over the PCB as this would affect its performance. The single loop wire quad is simpler in this regard, as it could be attached at one corner to the PCB. The higher gains of some antennas look attractive but may not be useful in practical mesh networks. To achieve the highest gain, careful adjustment of the antenna position and significant nodes and nulls was observed as the antennas were rotated. This adjustment is fine in a traditional pointpoint WiFi link, but in a mesh network, their are multiple nodes that need to communicate with another. The reason is that if a person peaks the response to one node, the person may dip the response to another.
The PCB mono poles perform well and are very simple. They consist of a 17 × 3 mm track on the PCB adjacent to a suitable ground plane, which can also be on the PCB. Both the 17 and 20 mm versions worked well, which suggests a relatively wide bandwidth and a high tolerance to small variations in manufacture like  dielectric constant of the PCB substrate. This is encouraging for low-cost mass production.

Power consumption
Without the FXS daughter board plugged in, the MP draws 1.92 W from an external power source. A D-Link DIR-300 doing the same would draw 2.28 W. With the FXS module installed, but idle (phone on hook) the MP draws 2.43 W. When a phone call is made (that is, the Radio and Ethernet are ON and BATMAN is running), the power consumption increases to 3.15 W.

Antenna range test
A nanostation was used at the transmitter that was sending continuous 802.11b broadcast pings. The antenna under test was placed about 6 m away, and a spectrum analyzer was used as the receiver. The various antennas in Section 5.2 were used during the test. When the antenna range was repeatedly varied for each antenna, remarkable results were obtained. The results showed that in order to have a high quality call using the preferred antenna (that is, the PCB mono-pole antenna with an N-type connector), the line-of-sight distance between two MPs must not exceed 375 m and the distance between an MP and a nanostation must not exceed 400 m.

Path loss
The path loss was calculated using WiFi power measurement formula, and its result was compared with the result obtained from a spectrum analyzer. The WiFi power measurement formula used is stated below. P r = TXpower + TXantennagain − pathloss + RXantennagain − coaxloss The total received power (P r ) obtained from the spectrum analyzer was -20 dBm, though the 802.11b signal peaked at about -30 dBm. Plugging in the numbers from the nanostation specifications (with its built-in 8 dBi gain Superpass omni reference antenna), a P r of -19 dBm was obtained.

Traffic scalability
A stability test was also conducted using the prototype MPs. Here, two MPs were allowed to run for up to five days at a time. A good result was obtained afterwardboth the OS (Linux) and firmware (WiFi) stayed up, and there was still a dial tone from both FXS ports. This test proved that the MPs have no memory leaks and CPU instability, though there was drastic temperature problem. The problem was traced to the channel driver, and it was fixed. The MPs also passed a 24 h stability test that required making over 3,500 calls on them.
Another test was to make sure that a given MP node can relay 15 phone calls for other people while simultaneously making a phone call of its own. This scenario places significant CPU load on the router due to the number of WiFi packets that must be processed at the same time as DSP intensive code, such as echo cancellation and speech compression. This test would provide a valuable information considering all the processing-Linux, WiFi, mesh, Asterisk, echo canceling, GSM speech compression, FXS driver-on the little MP router chip. With a total of 16 calls, the data rate was approximately 500 kbit/s, which proved that the bandwidth of the mesh was quite lightly loaded. However, speech packets were rather short. Hence, raising the number of phone calls would likely run into CPU overload due to the per-packet processing load, as well as limitations with the 802.11 air interface that arise when sending short packets.
Header compression is a complementary scheme related to aggregation [5,17]. The usage for header compression is motivated by the fact that (1) the VoIP payload is typically compressed at the application layer, which means another compression does not help reduce the payload size; (2) the headers occupies a large portion of the packet; and (3) the headers have significant redundancy.
Packet headers with redundancy may be reduced through compression techniques as has been done with great success for cRTP (Compressed Real-time Transport Protocol) and ROHC (Robust Header Compression) [5]. For a VoIP flow, RTP/UDP/IP headers take 40 bytes. However, only 12 bytes of them changes when the packets get routed. Schemes, such as cRTP or ROHC, aim at compressing the 40 bytes into a 2 byte connection ID. VOIP packets are very small compared to other traffic on a WiFi network. Consider a 33 byte GSM codec packet compared to a packet of web traffic that may be up to 1,500 bytes. To transmit this GSM codec packet using VOIP, a RTP header (12 bytes), a UDP header (8 bytes), and an IP header (20 bytes) must be added, thereby giving a total IP packet size of 73 bytes. To send one GSM codec payload packet every 20 ms (13.2 kbit/s) therefore requires an IP level bit stream of 29.2 kbit/s. There are further overheads due to the 802.11 MAC headers and protocol used to reliably transmit data over the WiFi channel, though they are optimized for larger packets (1,500 bytes).
Packet rate (measured in packets/s) is the key factor for VOIP over WiFi capacity, and one way to improve throughput is source aggregation. This requires sending multiple codec packets in every WiFi packet. Four GSM codec packets (per WiFi packet) have been experimented in this research. As a result, the VOIP call capacity has effectively increased at the expense of increased delay under packet loss conditions. Given the higher potential packet rates of 802.11 g, the MP nodes have been configured to only run 802.11 g. Whereas in 802.11 bg compatibility mode, the 802.11 g packet rates are limited to 802.11b levels.

Fitness for purpose
The VT project is unusual in that it is designed to operate in relatively extreme scenarios. Extreme scenarios here refer to infrastructure poverty, technical literacy poverty, and financial poverty. Thus, it is worthwhile to make comment on the performance of the technology with respect to these objectives.
First, the MPs have been demonstrated to work in areas where there is absolutely no supporting infrastructure (for example, the Australian Outback) and using simple power solutions (that is, bare batteries without supporting circuitry).
Second, the deployments in Dili and Bo-kaap were specifically targeted at an audience with low technical literacy. Here, the results have been mixed. On the one hand, it is extremely encouraging that in Dili, there are now second-generation indigenous trainers, who were trained by Timorese and are now training other Timoreses. As a result, it allows the deployment to grow and self-sustain without requiring first-world labor. Indeed, the operation of the MPs is so simple that most firsttime users begin to make and receive telephone calls in just a few minutes. However, the RF aspects of mesh management, including how to resolve intermittent interference problems, remain more complex and often require consultation of skilled practitioners. Some work is being done to create simple diagonstic tools and instructions in their use to allow for the intelligent placement and relocation of mesh nodes to resolve interference problems.
Finally, the mesh potato devices deployed to Non-Government Organizations (NGOs) in Dili have been enthusiastically embraced, and their users report great joy in what they often describe as "the gift of telephony". This term is not inappropriate, as the MP allows free calls between organizations, when the only alternative would be a GSM telephone call costing approximately US$0.25 per minute-a huge sum for a country where the typical daily wage is around US$1.50. Indeed, the effectiveness of the MP is beginning to be realized by governmental organizations and there are anecdotal reports of MPs being deployed into at least one police station and University. t The cost of an MP at approximately US$80-US$100 (plus often significant import duties) remains a barrier to adoption; however, the VT is actively working to lower the manufacturing and retail costs of the unit, with the goal of reducing the retail price in developing nations to below US$60.

Conclusions
WMNs could strengthen the social capital between people living in the same neighborhood and close the gap between virtual and physical communities by supporting a large variety of social and collaborative applications. Services and applications targeted for the rural communities using mesh networks include Web browsing, video conferencing, and Voice over Internet Protocol (VoIP) services and all of these services can be achieved with the Village Telco infrastructure. In this section, the paper is concluded with a summary, a brief discussion of the limitation of the reported study, and a presentation of related studies planned for the future.
This paper reported on the various preliminary tests, including the followings that were conducted on the MPs: Antenna Impedance, The Antenna Gain, Power Consumption, Antenna Range Test, Path Loss, and Stability Test. Antenna Impedance tests proved the feasibility of a low-cost PCB antenna, helping to keep the cost of the device low, although there is some room for improvement.
The power consumption tests revealed that when phone calls were made, the unit drew a mere 3.15 W, lower than similar devices, despite the inclusion of significant voltage protection measures, which is beneficial for off-grid deployments in the developing world.
Stability testing was also conducted using the prototype MPs. This test indicated that the MPs had no memory leaks and CPU instability, thus establishing that the current software stack is robust enough for initial adoption.
At this stage, the Village Telco architecture has been proved to be practical, but suffering from many of the expected interference and range limitations inherent in 802.11 WiFi. Not withstanding this, the tests have demonstrated that the technology is already usable, and indeed valued by users in developing nations, as evidenced by early deployments of the infrastructure.
Lastly, a number of related studies have been slated for the future. These include an evaluation and benchmarking conducted on the system, comparative analysis (performance evaluation, costs, etc.) between the VT and other competing systems, end user perception studies dealing with system functionality, usefulness, usability, ease of use, look and feel, cost versus benefit, and needed improvements and enhancement. Above all, the MP has proven to be effective and valuable to its users, with its major strengths being the low cost of the unit and ease of deployment and management.