Implementing voice over protocol in mobile ad hoc network – analysing its features regarding efficiency, reliability and security

Naveed Ahmed Sheikh1, Ashfaq Ahmad Malik1, Athar Mahboob2, Khairun Nisa3 1PN Engineering College, National University of Science & Technology, Karachi, Pakistan 2Department of Electrical Engineering, DHA Suffa University, Karachi, Pakistan 3Department of Computer Science and Engineering, University of Engineering & Technology, Lahore, Pakistan E-mail: [email protected]; [email protected]

Published in The Journal of Engineering; Received on 1st February 2014; Accepted on 4th March 2014

Abstract: Providing secure and efficient real-time voice communication in mobile ad hoc network (MANET) environment is a challenging problem. Voice over Internet protocol (VoIP) has originally been developed over the past two decades for infrastructure-based networks. There are strict timing constraints for acceptable quality VoIP services, in addition to registration and discovery issues in VoIP end-points. In MANETs, ad hoc nature of networks and multi-hop wireless environment with significant packet loss and delays present formidable chal- lenges to the implementation. Providing a secure real-time VoIP service on MANET is the main design objective of this paper. The authors have successfully developed a prototype system that establishes reliable and efficient VoIP communication and provides an extremely flexible method for voice communication in MANETs. The authors’ cooperative mesh-based MANET implementation can be used for rapidly deployable VoIP communication with survivable and efficient dynamic networking using open source .

1 Introduction also a bandwidth constraint in such a wireless network because it lacks access points and high-speed wired links. Furthermore, Our objective in this paper was to develop a prototype system to es- since the current routing protocols do not focus much on the secur- tablish reliable and efficient voice over Internet protocol (VoIP) ity aspects, MANETs are also more vulnerable to security threats as communication and provide an extremely flexible method for compared with traditional wired networks [3]. VoIP in mobile ad hoc networks (MANETs) using Smartphone and tablets running the Android operating system. We successfully 2.2 Survey of MANETs implementations on Android established cooperative mesh-based MANET with optimised link state routing (OLSR) as the routing protocol for rapidly deployable Ad hoc networking support on Linux-based and desktop PCs VoIP communication. The system is survivable and efficient sup- has matured in recent years [4]. However, it is still an open research porting dynamic networking using open source software (OSS) problem for Android devices reason being that Android Open Source modules such as modified wireless fidelity (WiFi) [1] Project has not formally supported ad hoc network implementation in and PTTDroid [2] VoIP application. Android Kernel [5]. Primarily, Android OS is designed to work in in- After this short introduction Section 2 discusses the background frastructure mode or managed network scenario. In a managed information. Section 3 is about solution implementation and network, the client is connected to an access point (AP) after describes the configuration of the application on Android and per- authentication. It utilises the wpa_supplicant command line utility sonal computer (PC) platforms. Section 4 covers security aspects for configuration as is done in standard Linux as well. Ad hoc net- considered for the proposed application. Section 5 discusses works on the other hand do not use AP devices for centralised man- performance-based results gathered on pre-set criteria. Finally, we agement and each device has the capability to do the routing for conclude and discuss future work in Section 6. others. The versions of Android older than the Ice Cream Sandwich (ICS) only supported managed networking. The 2 Background information direct-WiFi utility in ICS also does not cater to full ad hoc support. Hence, one has to resort configuring wireless chip through use of 2.1 MANETs iwconfig command supplying the parameters of wireless interface. MANETs are peer-to-peer self-organising networks and do not The Linux Kernel must also support wireless extension (WEXT) ap- require a fixed infrastructure. The nodes of a MANET have to self- plication programming interface (API) [6]. Next, we review some of configure in some arbitrary manner in order to perform their func- existing approaches to enabling ad hoc networking in Android. tion in the absence of a fixed infrastructure. The areas with depleted The Smartphone ad hoc network (SPAN) project [7] has con- fixed infrastructures can be a place where a natural disaster has oc- ducted significant work in this area and has developed few applica- curred such as an earthquake, flood or where a chaotic situation has tions such as MANET Manager, MANET Voice Chat and MANET been created by humans such as in a battlefield. The MANET nodes Visualiser. Stoker’s SPAN project used Mueller’s WiFi Wireless can directly communicate with each other because either they are in Tethering [8] initially. Its functions include tethering and executing the required radio range of each other or otherwise multi-hop the OLSR Daemon. Its graphical user interface (GUI) is very user routing can be used to establish connectivity. Well-known multi- friendly. However, it only supports WEXT Kernel resulting in ap- hop routing protocols include OLSR, a proactive routing protocol plicability to a limited number of Android devices. Samsung and ad hoc on-demand distance vector, a reactive routing protocol. Galaxy Tab 10.1, S II Epic Touch 4G SPH-D710, Nexus Since the MANET nodes may be in continuous motion and may SCH-I515, S III GT-I9300 I9300UBDLJ1, S-IIIGT-I9300, move into and out of the radio range of each other, frequent break- I9300XXBLH1 and ASUS Transformer Prime TF201, Nexus-7 age of data links can occur, resulting in high vulnerability of wire- are the devices supported by SPAN’s MANET Manager [6]. less link between nodes. The topology of a MANET is highly We have also successfully tested SPAN’s MANET Manager ap- dynamic, therefore routing information also changes. There is plication with limited functionalities on XPOD Bubblegum Tablet

J Eng 2014 This is an open access article published by the IET under the Creative Commons doi: 10.1049/joe.2014.0035 Attribution License (http://creativecommons.org/licenses/by/3.0/) 1 (installed with ICS 4.0.4) and XPOD Tabloid running Jelly Beans (JB 4.1.1). Details are provided in the implementation section. However, it did not run successfully on all Smartphone devices such as Q-Mobile A8 or A950 installed with JB 4.1.1. Commotion [9] is another project demonstrating work on mesh networking for Android-based Smartphone, tablets, , PCs, cellular networks and routers. The characteristic features of their implementation include tethering and executing OLSR protocol. It has a user friendly GUI. However, several shortcomings of their implementation hinder it from wide adoption. These include failure of proper execution of tethering application. Consequently, OLSR protocol also fails to execute. There are a few other projects also that have worked on MANETs or mesh networks on Android platform such as Thinktube [4], Barnacle [10], [11], WiFi Tethering by Opengarden [12], WiFi ad hoc Enabler [13], Serval [14] etc. In our paper, we have mainly improved the WiFi Wireless Tether [8] application to work reliably in ad hoc mode along with OLSR. Details are pro- vided in the implementation section. Fig. 2 Ad hoc network configuration

2.3 VoIP in MANET Following configuration was set on laptop running with The VoIP technology has been a hot issue in the Information Ubuntu-12.04: Technology industry for more than ten years now. Providing a secure real-time VoIP service on the MANET is the main design objective of this research. It is perceived to be a difficult task † sudo ifconfig wlan0 10.10.10.10 netmask 255.255.255.0 because of restrictions in device resources, adverse properties of † sudo iwconfig wlan0 mode ad hoc the wireless channel, dynamic topology and the lack of central ad- † sudo iwconfig wlan0 essid ‘test’ ministration. In addition, the flexibility of the VoIP system and the † sudo iwconfig wlan0 channel 4 convergence of voice and data networks bring in additional security † sudo iwconfig wlan0 key off risks. All devices in an Internet protocol (IP) network become po- tential active or passive adversaries. It can be seen that the under- lying IP data network facility that a VoIP system relies on Owing to some built-in shortcomings of the Android JB 4.1.1 for complicates the security assurance requirement. XPOD Tabloid, the ad hoc node with essid ‘test’ could not be detected on the Tabloid device. However, it was displayed as (*) test on XPOD Bubblegum Tablet which was connected in ad hoc 3 Solution implementation mode with Ubuntu laptop. Following routing information was also updated on XPOD tablets as shown in Fig. 3. 3.1 Implementing MANET Manager The Stoker’s MANET Visualiser application created following As already discussed in Section 1, Stoker’s MANET Manager has link diagram as shown in Fig. 4. contributed significantly to implementation of ad hoc network on Using MANET Manager’s built-in messenger, hello chat mes- Android devices. We were able to localise two low-end Android sages were also exchanged on both tablets as shown in Fig. 5. tablets available as commercial off the shelf (COTS) which support WEXT and successfully installed MANET Manager appli- cation available on Play Store [5]. This was managed by lot of testing and trials. Snapshot of MANET Manager running in ad hoc mode is shown in Fig. 1. XPOD Bubblegum and Tabloid Tablets were assigned IP addresses as 10.10.10.20/24 and 10.10.10.60/24. However, the tablets did not connect to each other in ad hoc mode. A special ar- rangement was made as shown in Fig. 2.

Fig. 1 Running MANET Manager snapshot Fig. 3 Routing information on MANET Manager

This is an open access article published by the IET under the Creative Commons J Eng 2014 Attribution License (http://creativecommons.org/licenses/by/3.0/) doi: 10.1049/joe.2014.0035 2 Fig. 6 Modified WiFi ad hoc system features

Fig. 4 Link diagram by MANET visualiser purpose as shown in Fig. 7 by ‘Change IP’ option. A text box is added that takes an IP address given by the user as input. This feature makes the network dynamic by allowing any two nodes to The VoIP communication between these tablet devices config- connect with each other. As a result, user does not have to ured in ad hoc mode could not be satisfactorily established depend on dynamic host control protocol (DHCP) service to despite several attempts using MANET Voice and PTTDroid assign an IP address to the nodes connecting in the network. VoIP applications. This may be attributed to non-fulfilment of hard- (3) OLSR: When the start button is pressed in tethering application, ware support for MANET Manager installed. This forced us to a file olsr.conf is fetched from memory containing OLSR configur- explore other methods to establish ad hoc networks to run VoIP ation. This configuration drives the information sharing process of successfully. topology. OLSR is a proactive routing protocol and is required for multi-point relaying (MPR). MPR helps in increasing the diameter 3.2 Implementation using WiFi Wireless Tether app of MANET network by allowing two or more nodes to connect (1) Preparation: The WiFi Wireless Tether application [8] men- through single or multiple bridges. tioned earlier was tried. We describe the experience with WiFi (4) Neighbour recognition: It is essential to know about neighbours Tether app below. The existing WiFi Tethering application was in order to communicate with them. This feature helps in recognis- tried as a basis of our mesh network for VoIP communication ing the name and IP address of neighbours. The function picks in- formation generated by OLSR for display purpose. system. Original WiFi Tether application does not have the func- fi fi tionality of defining an IP address while executing the application. (5) Con guration of system: The con guration steps are different fi depending on whether the device uses a full-blown Linux-based An ad hoc node is assigned a xed IP address. This restricted the fi system in becoming a pure MANET. It also lacked the feature to system or an embedded Linux system. Each step of the con gur- ation needs to be executed in a methodical way to achieve a reliable track topology information and neighbour recognition. The fi enhanced system thus developed and implemented covers all setup of the ad hoc network. Con gurations are done to build a con- these aspects along with VoIP functionality. The overall improve- nection between the devices to form a MANET, and hence be able ments are shown in Fig. 6. The implementation has been sub- to perform VoIP communication. If both devices are of the same divided into multiple sections which are discussed in the type, they follow the same setup procedure. (6) Setup on PC for real-time monitoring: Fig. 8 shows different subsequent sub-sections. fi (2) User defined IP: The existing system is modified to accept a user steps involved in installation of OLSR, its con guration, inserting defined IP. On the user interface, a section is provided for this required plugins and mapping software for ad hoc nodes.

Fig. 5 Exchange of hello messages Fig. 7 Static IP option

J Eng 2014 This is an open access article published by the IET under the Creative Commons doi: 10.1049/joe.2014.0035 Attribution License (http://creativecommons.org/licenses/by/3.0/) 3 Fig. 8 PC setup

To install OLSR [15], a set of pre-requisite software tools are required. These comprise of flex, bison, libc6 and git-core. These can be installed using standard software installation procedure. Fig. 10 Android setup steps Once OLSR is installed with its pre-requisites, it is configured. The OLSR configuration file is set to optimise its response time for detecting nodes entering and leaving the system. There are (CLI) on Android. It is the same thing as using a CLI on a Linux five plugins of OLSR that are inserted, namely: TXT INFO system. Busybox helps in the execution of the basic commands PLUGIN, HTTP INFO PLUGIN, DOT DRAW PLUGIN, NAME of Linux on Android devices. SERVICE PLUGIN and OLSR SECURE PLUGIN. These OLSR is then built on PC for Android compatibility using a plugins are used to observe information provided by OLSR in a cross-compiler. A number of different utilities and tools are user friendly way. required to build the OLSRd for Android. These include bison, fl Ubuntu 12.04 is joined to ad hoc network using the default ex, libc6, Android-software development kit (SDK), Android- network manager. It is a user interface that interacts with WiFi pro- native development kit (NDK), git-core etc. tected access (WPA) supplicant file for smooth interaction between Both the Android SDK and NDK are also required. These are hardware and software layers. An IP address is given to the device extracted and installed in /opt folder to avoid build failures. NDK fi fi fl to be recognised on the network. Channel is selected to join a base le location is updated in the Make le to re ect the actual lo- network operating on a specific frequency. Service set identifier is cation of extracted development toolkits. The following commands also set to give the wireless network a recognisable name. OLSR are executed to generate Android compatible OLSRd: is then executed. Multiple packages are required to make the #make OS = Android DEBUG = 0 plugin work that draws the network topology. These packages NDK_BASE = /opt/Android-ndk contain commands that are given for visual graphics. The graphical #sudo make OS = Android DEBUG = 0 install_all view of the network topology is generated in real time. Fig. 9 shows fi an example of the topology view that is generated when different The WiFi Tether application is con gured to copy the latest olsrd. nodes are connected in the network. conf to the system/etc folder every time it starts, making it easy to change configuration at any stage, even if root exploration is not possible. 7. Setting up custom WiFi Tether and VoIP on Android: The steps The files generated while creating Android compatible OLSRd involved in setting up of Custom WiFi Tether and PTTDroid VoIP are copied on the Android phone. Interfaces can be verified application are highlighted in Fig. 10. through Android Terminal Emulator by executing netcfg command. This command lists the interface that is responsible for WiFi connectivity. They can be modified in the OLSRd configur- There are multiple methods for rooting Android phones depend- ation file to suit the requirement of connecting to an operational ing on device [16]. However, there is a universal method as well. wireless interface. The custom WiFi Tether application and We used the universal method to root the phone. Android terminal PTTDroid application are then installed. emulator and busybox are installed from Store. After installation, the icon for the WiFi Tether is made available Android terminal emulator helps in giving a command line interface on the Application Drawer Panel and is executed by first tapping over the app icon. After successful implementation of ad hoc network and launch the OLSRd, we again move to the application drawer and look for the PTTDroid application icon and execute by tapping over it. To establish a voice connection, the IP address is supplied in the configuration option of the application and commu- nication is commenced by tapping over the microphone icon and holding it for the time the user needs the voice to be sent over to the target. As soon as the user lifts his/her finger from the micro- phone icon on the screen, the application switches out of the sending voice data mode, although the device remains to be in the listening mode that is, receive data at all times.

4 Security aspects Multiple options were explored to secure the VoIP system. The ob- jective is to avoid unauthorised access to the MANET. The CSipSimple VoIP application [17] could not be used. It has a Fig. 9 Topology overview feature in which it calls on the Android network manager which

This is an open access article published by the IET under the Creative Commons J Eng 2014 Attribution License (http://creativecommons.org/licenses/by/3.0/) doi: 10.1049/joe.2014.0035 4 is consulted to check the wireless interface state. As the system is Table 1 Jitter values range functional in ad hoc mode and unfortunately because of Android’s lack of native ad hoc mode supports the network Qualities Ranges, ms Remarks manager indicates to the software that WiFi state is off, the software fails to execute indicating the WiFi state. For security of VoIP good 0–20 acceptable during transmission, we encrypted the data using a custom encryp- average 20–30 marginally acceptable tion software. Owing to heavy processing load and limited process- poor above 30 not acceptable ing power that stream ciphering operation required, PTTDroid Application halted leaving it unresponsive and unstable, and hence became unusable for the system. As another approach to Table 2 Packet loss percentage range improve encryption performance, IPSec tunnelling was implemen- ted and packets were analysed with the help of the Wirehshark in Qualities Ranges, % Remarks promiscuous mode. It was discovered that the channel was indeed being established with the help of Internet Security Association good 0–1 acceptable and Key Management Protocol negotiation. However, the tunnels average 1–2.9 marginally acceptable were not activated and data were not transferred as the nodes poor above 3 not acceptable remained stuck in negotiating the parameters for IPSec connectiv- ity. Although the methods listed above were all valid approaches towards securing the VoIP system, every method had some (3) Jitter: Jitter is the variance in measuring successive ping tests. deficiency. Zero jitter means the results were exactly the same every time We applied the mechanism for securing the OLSR protocol as and anything above zero is the amount by which they varied. implemented in [18] as an extension to the OLSR source code pro- Like the other quality measurements, a lower jitter value is better. vided from UniK [15]. The mechanism is based on signing each While some jitter should be expected over the Internet, having it OLSR control packet with a digital signature for authenticating be a small fraction of the ping result is ideal. Table 1 shows the this message. In addition, the mechanism provides a timestamp ex- values for jitter [19]. change process. The timestamps are used to prevent replay attacks on the OLSR routing protocol. This security mechanism does not Jitter was also measured using ‘iperf’ for Android. The following need synchronised time. It only secures the routing messages and commands are used: not the user traffic being routed in the MANET. A pre-shared key file is placed at a known location in all the # iperf -s -u -i 1 (on server or side) nodes. If it matches, that is, verified, the packets are accepted and # iperf -c 10.10.10.40 -u -i 1 -t 60 (on client side) OLSR sending node joins the network. If the signature cannot be fi veri ed, the message is discarded and the node sending the (4) Signal strength and signal-to-noise ratio (SNR): This is mea- packet is prevented from joining the system. The same method is sured with the help of a simple app named WiFi analyser. The used as well for the intrusion detection. If someone is trying to values given are in dBm, that is, it is the measure of the absolute join the network without a key, as it does not contain the digital sig- power received by the node at a given point. SNR is the ratio of nature and therefore it is rejected by the OLSR Daemon. The sender the received RF signal, to that of background noise. SNR of IP address is also displayed on such action in the running OLSR greater than zero signifies that the received signal power is greater Daemon. This can be viewed in the terminal emulator of the than the background noise. Android GUI. (5) Packet loss: If you have anything less than complete success in transmitting and receiving ‘packets’ of data, then you are experien- 5 VoIP quality performance results cing this problem with your Internet connection. It can mean much 5.1 Parameters slower download and upload speeds, poor quality VoIP audio, pauses with streaming media etc. Packet loss is a metric where any- In this section, we provide VoIP performance results using our thing greater than 0% should cause concern. Packet loss range of implemented system. The results were collected for two different values have been categorised in Table 2 [19]. scenarios. Results are collected for each of the parameters men- (6) Mean opinion score (MOS): MOS is a test used for telephony tioned below along with the tools used for performance networks to obtain user’s views for quality of network. It is a sub- measurement: jective measurement. We have used following criteria of MOS as per Table 3 [20] for rating quality of VoIP on our MANET imple- (1) Ping: It is used for measuring the round trip time (RTT) taken mentation and an average score is calculated through a survey of 20 by the packets from source to destination and way back in the people. network. Total time taken is measured in milli-seconds (ms). The command used for measuring it is as follows: 5.2 Scenario-1 (maximum distance 500 ft) In this scenario, performance values are collected for the # ping -c60 10.10.10.40 node-to-node connectivity using line of sight approach, that is, no barriers. An illustration of scenario is shown in Fig. 11. It gives (2) Throughput and bandwidth: Throughput is the average rate of successful message delivery over a communication channel and is Table 3 Sound quality–MOS chart generally measured in bits per second (bps). This is measured with the help of ‘iperf’; a simple application installed in Android MOS Qualities Impairments which calculates the amount of data transferred and the optimum bandwidth achievable. The ‘iperf’ command used for it is as 5 excellent undetectable follows: < colcnt = 1 > 4 good detectable but not annoying 3 fair slightly annoying # iperf -s -i 1 (on server or side) 2 poor annoying # iperf -c 10.10.10.40 -i 1 -t 60 (on client side) 1 bad very annoying

J Eng 2014 This is an open access article published by the IET under the Creative Commons doi: 10.1049/joe.2014.0035 Attribution License (http://creativecommons.org/licenses/by/3.0/) 5 Fig. 11 Node–node scenario

Fig. 15 Jitter against distance

Fig. 12 Ping RTT against distance

Fig. 16 Signal strength against distance

Fig. 13 Throughput against distance

Fig. 17 SNR against distance

the idea of the way these tests are conducted in the real-world environment. The following graphs in Figs. 12–21 illustrate the network per- formance giving the idea of how the ad hoc network performed for the above-mentioned parameters.

5.3 Scenerio-2 (maximum distance 800 ft) In this case, values are collected for the node–bridge–node scenario using line of sight approach that is, no barriers between node– bridge but at the same time node–node are out of sight. In short, Fig. 14 Bandwidth against distance nodes are connected via a bridge. A case scenario illustration is

This is an open access article published by the IET under the Creative Commons J Eng 2014 Attribution License (http://creativecommons.org/licenses/by/3.0/) doi: 10.1049/joe.2014.0035 6 5.4 Summary of results The overall results are summarised for both the scenarios as under:

Features Scenario 1 Scenario 2

ping acceptable acceptable jitter acceptable acceptable signal strength acceptable NA SNR acceptable NA bandwidth acceptable acceptable throughput acceptable acceptable packet loss acceptable acceptable MOS-quality of sound (with 3.95 kbps) good good Fig. 18 Packet loss (percentage against distance) MOS-quality of sound (with 24 kbps) good good MOS of quality of sound (without Codec) good average

Fig. 19 Sound quality with Codec at 3.95 kbps

Fig. 22 Node–bridge–node scenario

Fig. 20 Sound quality with Codec at 24 kbps

Fig. 21 Sound quality without Codec shown in Fig. 22 giving the idea of the way these tests are con- ducted in real-world environment. The results are collected and measured on the same pattern as the first test case scenario. In this case scenario, a Smartphone is used as bridge between two nodes that acts as relay for communication. The bridge is active but does not take part in the communication nor can Fig. 23 Ping RTT against distance it hear any communication between the two end nodes. The maximum distance between the node–bridge is 400 ft, whereas the distance between the two end nodes is collectively 800 ft. The Results provided in this section indicate that an acceptable entire tests have been taken starting from 200/200 ft setting and quality for VoIP service can be established up to distances of ended up at 400/400 ft. The results are plotted in graphs as 800 ft in the MANET, even when packets are relayed by an inter- shown in Figs. 23–30. mediate node and using the COTS Android Smartphone devices.

J Eng 2014 This is an open access article published by the IET under the Creative Commons doi: 10.1049/joe.2014.0035 Attribution License (http://creativecommons.org/licenses/by/3.0/) 7 Fig. 28 Sound quality with Codec at 3.95 kbps

Fig. 24 Throughput against distance

Fig. 29 Sound quality with Codec at 24 kbps

Fig. 25 Bandwidth against distance

Fig. 30 Sound quality without Codec used

6 Conclusion and future works 6.1 Conclusion We have successfully developed a prototype system which has established secure VoIP communication and also provides an ex- tremely flexible method for VoIP in MANETs. Hence, we can con- clude that we were able to establish a cooperative mesh-based mobile ad hoc network for rapidly deployable VoIP communication with survivable, efficient, dynamic and secure networking.

Fig. 26 Jitter against distance 6.2 Future works The customised WiFi Tether application can be worked out further to make it more flexible by doing research and implementing dynamic IP addressing, encryption of packets, providing full duplex mode of communication and by enhancing GUI for enhan- cing user experience. We are exploring further ways to improve on the Commotion, MANET Manager and other similar projects to have reliable and generic solutions in MANETs or mesh networks. We are also endeavouring for IPSec implementation in our Android ad hoc network solution to have end-to-end security.

7 References

[1] Google web page. Available at http://www.code.google.com/p/ Android-wifi-tether/downloads/list, visited on 28 September 2013 [2] Google web page. Available at http://www.code.google.com/p/ Fig. 27 Packet loss against distance pttdroid/, visited on 28 September 2013

This is an open access article published by the IET under the Creative Commons J Eng 2014 Attribution License (http://creativecommons.org/licenses/by/3.0/) doi: 10.1049/joe.2014.0035 8 [3] Malik A.A., Khan M.A., Mahboob A., Haider F.: ‘Secure geo-sharing [12] WiFi Tether web page. Available at https://www.play.google.com/ in MANETs’. Proc. IEEE Int. Conf. Collaboration Technologies & store/apps/details?id=og.Android.tether, visited on 26 September Systems CTS-2012, 2012, pp. 59–64 2013 [4] Chang L.-H., Sung C.-H., Chiu S.-Y., Lin Y.-W.: ‘Design and realiza- [13] WiFi Ad Hoc enabler for Android web page. Available at http://www. tion of ad-hoc VoIP with embedded p-SIP server’, J. Syst. Softw., arenddeboer.com/wifi-ad-hoc-enabler-for-Android, visited on 25 2010, 83, (12), pp. 2536–2555 September 2013 [5] Thinktube Inc: ‘Ad-Hoc (IBSS) mode support for Android 4.2.2’ [14] The Serval Project. Available at http://www.servalproject.org Page. Available at http://www.thinktube.com/component/content/ [15] OLSRd an Adhoc Mesh Routing Protocol Home Page. Available at fi article/19-technicalinformation/46-Android-wi -ibss, visited on 01 http://www.olsr.org/, visited on 01 November 2013 November 2013 [16] Raja H.Q.: Addictivetips Home Page. Available at http://www. [6] Thomas J., Robble J., Modly N.: ‘Off grid communications with ’ addictivetips.com/mobile/how-to-root-your-Android-phone-device/, android meshing the mobile world . 2012 IEEE Conf. Technologies visited on 08 November 2013 for Homeland Security (HST), 13–15 November 2012, pp. [17] Google web page. Available at http://www.code.google.com/p/ 401–405, doi: 10.1109/THS.2012.6459882 csipsimple/, visited on 01 November 2013 [7] Stoker’s MANET Manager. Available at https://www.play.google. [18] Hafslund A., Tønnesen A., Rotvik R.B., Andersson J., Kure O.: com/store/apps/details?id=org.span&hl=en ‘ ’ [8] Android WiFi Tether. Available at http://www.code.google.com/p/ Secure extension to the OLSR protocol . Published in Proc. OLSR Android-wifi-tether/, web page visited 20 September 2013 Interop and Workshop, 2004 [9] Commotion project home page. Available at https://www. [19] Telecompute Voice Over Internet Protocol (VoIP) Page. Available commotionwireless.net/ at http://www.telecompute.com/voip.asp, visited on 23 December [10] Barnacle WiFi Tether web page. Available at http://www.szym.net/ 2013 barnacle/, visited on 25 September 2013 [20] Wikipedia Mean Opinion Score Page. Available at http://www.en. [11] Opengarden Project web page. Available at http://wwwopengarden. wikipedia.org/wiki/Mean_opinion_score, visited on 23 December com/, visited on 26 September 2013 2013

J Eng 2014 This is an open access article published by the IET under the Creative Commons doi: 10.1049/joe.2014.0035 Attribution License (http://creativecommons.org/licenses/by/3.0/) 9