MPMobVis: Mesh Potato Mobile Visualization, Monitoring and Provisioning

Transcription

1 Honours Project Report MPMobVis: Mesh Potato Mobile Visualization, Monitoring and Provisioning Veenesh Jeena Supervised by: Professor Edwin Blake Co supervisor: Professor Gary Marsden Category Min Max Chosen 1 Software Engineering/System Analysis Theoretical Analysis Experiment Design and Execution System Development and Implementation Results, Findings and Conclusion Aim Formulation and Background Work Quality of Report Writing and Presentation Adherence to Project Proposal and Quality of Deliverables Overall General Project Evaluation 0 10 Total marks Department of Computer Science University of Cape Town i

2 Abstract Providing services such as internet connectivity and telephony services to rural areas involve a high cost of installing equipment, lack of reliable power and skills shortages. With the emergence of wireless technologies, access to these services is becoming easier and cheaper to provide in rural areas, mainly because these networks require little or no infrastructure, as opposed to wired networks. Management and maintenance of Wireless Mesh Networks (WMNSs) is an important task, however, managing wireless mesh networks are harder than managing wired networks, due to problems like resource constrained devices, nodes installed in hard to reach places and fluctuating link qualities. Problems faced by WMN deployments in rural areas that necessitate a need for an alternative network managing system to a laptop or desktop pc is that, these areas face regular power interruptions, have very dusty conditions with no proper housing for network servers Our goal for this project will be to demonstrate the feasibility of visualizing, monitoring and provisioning a WMN using a mobile phone. To demonstrate this, we will setup a WMN testbed consisting of wireless routers forming an ad hoc network. Using this network, we developed an application that will allow us to visualise and monitor the network. It also allowed us to develop provisioning tools for the phone to provision nodes onto the network. We found that monitoring the network using a mobile phone is possible. The phone is able to retrieve network information from the nodes, process it and display up-to-date network information to the user. There are limitations to what can be accomplished. We found that as the network grows, it takes increasingly longer to retrieve network data which is unsuitable for the user experience on a mobile phone. The screen size of the phone also presents a problem, as the whole network topology cannot be displayed without cluttering the screen. For this reason we presented a localized view of the topology, based on the user s position in the network. We discovered that while monitoring a wireless mesh network on a mobile phone is achievable, it is better suited as a supplementary tool for network management, and not as a replacement for traditional pc servers. ii

3 Acknowledgments I would like to firstly thank my parents, Ramesh Jeena and Jayoti Jeena, whose hard work and support allowed me to be where I am today I would like to thank our Supervisor, Professor Edwin Blake for the project proposal and his guidance in the writing of the thesis, and our Co supervisor Gary Marsden for his assistance on this project In addition, I would like thank Dr. Hahn Le, for her insight on this project Lastly, a thank you to my colleagues, Zaheer Abrahams and Tatenda Chipeperekwa, as this project would not have been the same without them iii

4 Table of Contents Abstract... ii Acknowledgments... iii List of Figures and Tables... vi Chapter 1 Introduction... 1 Chapter 2 Background Introduction to Wireless Mesh Networks Other Types of Wireless Ad Hoc Networks Uses of Wireless Mesh Networks Wireless Mesh Network Deployments The Wray Wireless Mesh Network Peebles Valley Mesh The Village Telco The Mesh Potato The BATMAN routing protocol Smartphone Platforms Open Source vs. Propriety Systems Network Interface Control Development Environment Wireless Network Management Network Management Tools Afrimesh MeshMan ReMesh Comparison of Network Management Tools Network Performance and Bandwidth Monitoring Self-Reconfiguration and Fault Management Conclusion Chapter 3 Design Scope and Aim of Design System Architecture iv

5 Hardware Software Overview of Android OS and Network Testbed The Mesh Network Testbed The Afrimesh Visualization Server The Mesh Potato The HTC Legend Android Handset Mesh Potato Monitoring Architecture JavaScript Monitoring Component Java Monitoring Component Project Component Interfaces Monitoring and Provisioning Monitoring and Visualization Conclusion Chapter 4 Implementation Challenges Connecting the Phone to the Mesh Network Connecting Mobile Phone to Server Issues Faced Testbed Connectivity Village Bus on the mobile phone Chapter 5 Evaluation Network Setup Test Descriptions and Results Test 1: Add MP to network Test 2: Remove MP from network Test 3: Network response time Test 4: Time taken for finding the closest node Test 5: Mobile phone battery life Areas not investigated Discussion v

6 Chapter 6 Conclusion Future Work References Appendix A: Test Results List of Figures and Tables Figure 2-1: An example of a decentralized wireless mesh network, providing internet services to mobile and fixed clients... 3 Figure 2-2: The beta version of the Mesh Potato... 6 Figure 2-3: Afrimesh displaying the network topology, for a four node network Figure 2-4: Afrimesh provides a view of network logs through its web interface Figure 3-1: An example of a mesh network, and the resultant display on the mobile phone, based on the users location in the network Table 3-1: The network settings used on the mesh network testbed Table 3-2: Table with the wireless card specifications used by the Afrimesh server to connect to the network Table 3-3: The hardware specifications of the Mesh Potato Table 3-4: The hardware and software specifications of the HTC Legend Android handset Figure 3-2: Overview of how the mobile phone will communicate with network nodes Figure 3-3: Architecture of the Monitoring component, and how each of the smaller modules interacts with each other Figure 3-4: Graph displaying the total network traffic (in packets) over time Figure 3-5: Interaction between each of the project components, and the mesh network Figure 5-1: The mesh network testbed consisted of a server and four of the beta Mesh Potatoes 29 Table 5-1: The time taken for a new node to be recognized Table 5-2: The time taken for a missing node to be recognized Figure 5-2: Graph depicting the network response times to collect data, as the amount of nodes on the network increases Figure 5-3: Graph showing how long it takes Monitoring to find the closest node, as the network size grows Table 5-3: The battery life of the HTC Legend while running the application vi

7 Chapter 1 Introduction Providing services such as internet connectivity and telephony services to rural areas involve a high cost of installing equipment, lack of reliable power and skills shortages [28]. With the emergence of wireless technologies, access to these services is becoming relatively easier and cheaper to provide in rural areas, mainly because these networks require little or no infrastructure, as opposed to wired networks. Management and maintenance of Wireless Mesh Networks (WMNSs) is an important task [25], however, managing wireless mesh networks are harder than managing wired networks, due to problems like resource constrained devices, nodes installed in hard to reach places and fluctuating link qualities [15]. Tools have been developed to visualize and monitor WMNs; however, they are mostly web-based applications, running on a laptop or desktop pc. None that we know are based on mobile phones. It is for this reason that we will investigate the feasibility of visualizing and managing a WMN, as well as providing provisioning tools on a mobile phone. Providing a network management system on the mobile phone is important for use in rural areas. Problems faced by WMN deployments in rural areas that necessitate a need for an alternative network managing system to a laptop or desktop pc is that, these areas face regular power interruptions, have very dusty conditions with no proper housing for network servers. This makes the environment unsuitable for hosting a server on a desktop or laptop pc. Mobile phones could address this problem since they have a battery life longer than that of a laptop, requiring infrequent charges, and they are unsusceptible to the harsh environment. Our goal for this project will be to demonstrate the feasibility of visualizing, monitoring and provisioning a WMN using a mobile phone. To demonstrate this, we will setup a WMN testbed consisting of wireless routers forming an ad hoc network. Using this network, we developed an application that allowed us to visualise and monitor the network. It will also allow us to develop provisioning tools for the phone to provision nodes onto the network. The whole system is divided into three components: Visualization, Monitoring and Provisioning. Visualization will be responsible for displaying the network topology. Monitoring the network will be responsible for retrieving network data and then processing this data to make it available for Visualisation and Provisioning. Provisioning will be responsible for giving nodes new settings, and keeping their firmware up-to-date. This project is concerned with the Monitoring component. The research we would like to conduct would enable us to answer the following questions: 1. Can monitoring a wireless mesh network be effectively achieved on a mobile phone? 2. Can mobile phones be used as an alternative to laptop or desktop pc servers for monitoring a wireless mesh network? 3. What are the limitations with using a mobile phone for monitoring a wireless mesh network? 1

8 Chapter 2 Background This chapter provides an introduction to wireless mesh networks (WMN), and the benefits of using them. Examples of deployments of WMN's are then provided to show the real world applications of this technology. We then look at a case study of the Village Telco. The Village Telco is an important case study, as this is the context on which our project is based. We then look at different monitoring tools, to determine what the key features of network monitoring are Introduction to Wireless Mesh Networks Wireless mesh networks (WMN) consist of routers and clients. The routers are devices that have minimal mobility, and provide the routing of data within the network. Clients are devices that connect to the network like cell phones, laptops or other wireless devices to use the network services. A particular wireless mesh network may or may not be connected to the internet [25]. A characteristic of WMN's are that they are multi-hop networks. That is, packets are routed from one router to another until the destination is reached. This allows WMN's to operate over great distances by forming a path in a chain-like manner. Adding nodes to the network further increases the reach of the network. WMN s are also redundant, meaning, that when a node fails, the rest of the nodes can still operate. WMN's can be decentralized as well, meaning that there is no single server used to manage the transmission of data. Each node is responsible for its own routing. This makes the network more flexible, and can allow routing to continue even when a router is removed from the network. WMN s are also self-forming, meaning that the mesh network forms itself, once the nodes have been configured and activated. Below is an example of a WMN, displaying the above properties. 2

9 Figure 2-1: An example of a decentralized wireless mesh network, providing internet services to mobile and fixed clients 2.2. Other Types of Wireless Ad Hoc Networks A wireless mesh network is an example of a wireless ad hoc network [25]. An ad hoc network is a type of network where communication takes place wirelessly, and there is no infrastructure, like gateways or access points, to transmit data between network nodes. One type of a wireless ad hoc network is a mobile ad hoc network (MANET). MANETs are similar to WMNs in that they are both self-forming, wireless multi hop networks. Also, in both types of networks, nodes communicate directly, without the need for pre-existing infrastructure. These networks differ in that the nodes in a MANET are highly mobile, as opposed to WMNs [33]. The routers in a WMN are static, providing the backbone network for transmitting data, while the mesh clients can be static or mobile [25]. In a MANET, all nodes, routers and clients, are highly mobile, frequently changing links to other nodes [33]. Applications for MANETs include military communications, search and rescue operations as well as setting up virtual classrooms or conference rooms [33]. 3

10 Another type of wireless ad hoc network are wireless sensor networks (WSN). WSN are similar to WMNs in that they are both self-organized, multi-hop networks. WSNs consist of a large number of sensor nodes with limited power supply and limited capabilities [46]. They then transmit this data to a Base Station (BS) for further processing. This transmission is done via other sensor nodes, if a node is more than one hop away from the BS. The biggest drawbacks of WSNs are that once they are deployed, the nodes cannot replenish their limited power supply [46]. WSNs are used to collect environmental conditions such as temperature, humidity and speed [46], which has military and commercial applications, such as detecting earthquakes and monitoring other environmental changes in oceans, forests etc Uses of Wireless Mesh Networks A reason why WMNs are such an attractive technology, especially in developing countries like Africa, is that they are relatively cheap and can thus drive down the price of communication access. Also, WMNs can quickly form ad hoc networks that are particularly useful in disaster relief situations when normal communication is not possible [12]. Some of their uses are listed below: Voice over IP (VOIP): Wireless mesh networks can be set-up within a community, to provide telecommunications services. In these networks, once a user connects their router to the network, they will be enabled to make telephone calls to other users on the network [29][32]. Broadband internet: Communities can form a wireless mesh network amongst themselves to share broadband internet connections [27]. Community and neighbourhood networking: Nearby homes can form a wireless mesh network amongst themselves, enabling distributed file-storage, distributed file access and video streaming without the need to access the internet [25] Wireless Mesh Network Deployments We have discussed some of the applications of WMNs. Here we provide case studies of real world deployments of WMNs The Wray Wireless Mesh Network In 2003, Lancaster University was approached by the residents of Wray, a small village, to help provide the village with broadband internet. Lancaster University, in collaboration with the village set-up the Wray WMN. The purpose of the network was to provide the village with broadband internet, to help local businesses and schools. The nodes deployed in Wray are primarily LocustWorld mesh nodes, which were placed strategically around the village. The WMN backbone operates using the IEEE b standard and the Ad Hoc On-Demand Distance Vector (AODV) protocol [27]. The school already had broadband internet access, through a government funded initiative, so researchers used the 4

11 school as a gateway to the internet. Residents could then wirelessly connect to the internet using IEEE b network cards. Some of the problems faced by the deployment were several blind spots were created by tall building and trees. This was overcome by having multihop links around these obstacles. Signal interference was also a problem, due to the aerials of nodes being positioned too close to existing television aerials. To overcome this problem, the height of the node aerials were extended [27]. There were also problems with the software implemented. For example, LocustWorld's nodes would always select the first gateway, even if it was not the best. The lack of software and hardware unification also lead to other problems, which lead the researchers to manually configure some of the mesh nodes, losing the dynamic, self-configurability of a WMN [27]. The Wray WMN seems to be a success. It had positive impacts on how the residents communicate. Residents could now contact outlying farms to participate in village meetings. The local farmers also benefited, by using the internet to register newborn calves online, saving time and money. Additionally, the Wray villagers are using their expertise to help other villages to set-up their own WMNs [27] Peebles Valley Mesh Peebles Valley is located near the Kruger National Park, South Africa. The Peebles Valley wireless mesh network was set up in the Masoyi community, a rural village. The mesh consists of 9 nodes, and covers an area of 15 square kilometres [28]. The mesh network's purpose is to provide internet access and VOIP services to the schools, homes, farms and other clinics. A VSAT internet connection is supplied to the AIDS Care Training and Support (ACTS) clinic by a sponsor. This connection is the gateway to the internet for the rest of the mesh network [28]. One of the problems experienced by the Peebles Valley mesh was line of sight. Elevated points in the valley were chosen to place nodes, to connect the two sides of the valley. The lack of local skills was also a problem, as this is prevents the locals from sustaining the network. Electricity supply is also a problem. Although there is a supply, the Masoyi community experience power outages on average once in seven days, lasting 3 to 24 hours [28]. The community has benefited from the network. They save as much as $400 on telephone calls a month, due to the VOIP service of the network. One of the clinic staff member's daughter, used the internet to learn IT skills, and as a result, she has a job which makes use of her IT skills [28] The Village Telco The Village Telco [44], headed by Steve Song, was set up by Dabba, a South African telecommunications company, and the Shuttleworth Foundation. The goal for the Village Telco is to develop a village telephone communication system (called a telco) that would be affordable to rural and other communities and which would require little technical knowledge. The telco would serve as a business for a local entrepreneur within the community, who would maintain and manage the telco to generate revenue as a source of income. 5

12 The Village Telco is an open-source, open-hardware project (the application of open source principles and licenses to hardware design) [35], and therefore comprises of many opensource software packages, and their own specially developed wireless router, the Mesh Potato. Below are descriptions of the Village Telco components that are important to this project The Mesh Potato The Mesh Potato (MP) is the router developed and used by the Village Telco. The idea for the MP was thought up at a Village Telco workshop at the Shuttleworth Foundation [36]. The name Mesh Potato comes from combining the words Mesh with POTS (Plain Old Telephone Service) and ATA (Analogue Telephone Adaptor). Hence, the MP is a wireless mesh router with an RJ11 port to connect a regular POTS handset, and a RJ45 port to connect to any IP device. The MP was developed as the tool that the Village Telco would use in their aims to create a low-cost telephony business model. It was decided to create a new device, because existing devices are too expensive and there is no one device that contains the necessary components needed by the Village Telco [35]. A beta version of the Mesh Potato is pictured below. Figure 2-2: The beta version of the Mesh Potato Alternative wireless routers that supply VOIP functionality are: 6

13 Accton Mini-Router: This router is made by Open-Mesh [39]. However, it provides connections for Session Initiated Protocol (SIP) phones, and not VOIP. The reason for not using these routers, are that SIP phones are still expensive, hence this would not suit a rural community. SparkLan Wireless AP: This router is provided by SparkLan [42]. While it does feature VOIP connectivity, the firmware is not open. This router was not considered by the Village Telco, as they are an open-source project [45]. The Village Telco has benefited from their decision to create their own router. They have created a router that suits their specific needs. The MP is a rugged router, with weatherproof housing so that it can be attached to the outside of a house, or work inside if needed. It can also withstand power surges, over-voltage DC and static electricity. These designs were chosen to make the MP suitable to rural environments The BATMAN routing protocol An important decision to make when deploying a WMN is that of the routing protocol to use. The important characteristics of routing protocols are: the time they take to converge, how well they cope as the network grows and the manner in which they select prefered routes. There are three main classes of routing protocols: reactive, pro-active and hybrid. Reactive protocols only search for paths to nodes when there is data to send. The advantage of these protocols is that no bandwidth is wasted on control messages. The disadvantage of these protocols is the high latency time when transmitting data. Reactive protocols are well suited to an ad hoc network with highly mobile nodes. Proactive protocols establish routes to nodes whether data is transmitted or not. The advantages of these protocols are that they produce lower latency times for data transmission, since a routing path is already known. The disadvantage of proactive protocols is their slow reaction times to network changes, like adding or removing of nodes. Hybrid routing protocols combine the properties of reactive and proactive protocols. Hybrid protocols are more complex to implement than reactive or proactive protocols. We will now give a brief discussion of the routing protocol used by the Village Telco, the Better Approach To Mobile Ad hoc Networking (BATMAN). BATMAN, a proactive routing protocol, was created to overcome the shortcomings of the Optical Link State Routing Protocol (OLSR). The wireless network community, Freifunk, experienced performance issues, such as unstable routes between nodes, with OLSR as the network grew very large (about 300 nodes) [30]. This prompted Freifunk to develop a new routing protocol, for large static mesh networks. BATMAN relies on the decentralisation of knowledge about the best route through the network. Each node is only concerned about the direction in which information was received, and which direction to send information. BATMAN works as follows: All nodes periodically broadcast originator messages (OM) to its neighbours, to inform them of their existence on the network. Each OM contains the originating node's address, sending node's 7

14 address and a unique sequence number (to determine the recency of the OM). Neighbour nodes then broadcast OM to their neighbours. Eventually, all nodes are aware of their neighbours. When transmitting data through the network, the best route is established through links with low utilisation [30][1]. OLSR is a proactive routing protocol as well. It uses a link-state algorithm to determine the most efficient path between nodes. Each node transmits Hello messages, and the OLSR protocol sets up a set of nodes called multipoint relays (MPRs), such that each node is at least one hop away from an MPR node. Each MPR contains information of the localised network, and this information is shared with the other MPRs, such that, each MPR has a complete routing table of the whole network [1]. By selecting only a subset of network nodes to forward link information, OLSR minimises the number of topology control packets sent through the network [1]. Studies done by [1] and [30] have shown that BATMAN outperforms OLSR on various performance metrics. Some of the more important results show that BATMAN has a lower average hop count than OLSR, as well as a lower average number of route changes [30]. The CPU usage was also relatively low compared to OLSR as the number of nodes increased, while the memory usage of BATMAN was lower than OLSR when the network was greater than 30 nodes [30]. The packet delivery ratio of BATMAN was even significantly better than OLSR, especially when the number of hops increased [1]. From these results we can see that between BATMAN and OLSR, BATMAN is the better routing protocol for WMNs, especially when taking into consideration, hardware requirements (cpu load and memory usage), network reliability as well as network scalability Smartphone Platforms Cellphones are becoming ever-increasingly more powerful, with smartphones becoming more like personal computers (PCs) [18] each time a new smartphone is released. As we mentioned, the Village Telco is an open source project. In keeping with the open-source philosophy, we now present an evaluation of mobile operating systems (OSs) to determine which platform is best suited to develop software for network management. We will look at the following smart phone OSs: Android, released by Google, iphone OS, released by Apple, Blackberry, released by Research In Motion, Windows Mobile, released by Microsoft and Symbian, owned by Nokia Open Source vs. Propriety Systems Of the above mentioned OSs, the open source OSs are, Android and Symbian, while Windows Mobile, Blackberry and the iphone OS are propriety [5]. Being open source, the advantage that Android and Symbian have over the other OSs, is that they can be used by any hardware manufacturer, unlike the iphone OS which is locked to only one device or Blackberry which can be installed only on blackberry devices. Microsoft on the other hand, allows hardware manufacturers to use Windows Mobile, but at a cost of $8 to $15 per mobile device [5]. 8

15 Consequently, with the propriety OSs, one is limited to the amount of changes that can be made to the OS. In [5], the authors highlight the differences in these OSs. Their results show that of these five OSs, Android and Symbian allow the user the most freedom to modify their mobile phones, while Windows Mobile and Blackberry provide less freedom for modification and iphone OS allowing almost no modifications without the proper permissions. Furthermore, Android and Symbian allow any application to be installed on their systems, while iphone OS always requires the application to be verified by Apple before it can be installed. Blackberry allows unsigned applications to be installed in the phone, however, applications requiring lowlevel API calls require the author to purchase a $20 'code signing PIN' [38]. The iphone OS and Blackberry are also strongly controlled by their publishers, and developers are not allows to modify or extend most of the component of the OS [5]. It is unclear to what extent Windows Mobile allows installation of applications, although [21], [20] and [19] suggest that Windows Mobile allows installation of unsigned applications. Windows Mobile also has restrictions on which platform components can be modified, though this it is not as restrictive as the iphone OS or Blackberry [5] Network Interface Control One important feature that we would need is control over the network interfaces, especially the wifi interface. The reason for this is, because the Village Telco runs their mesh network in ad hoc mode, the device would need to be able to connect to the network in ad hoc mode. Of the OSs mentioned above, Android, Blackberry and Windows Mobile offer control over network interfaces. This means, that an application has the ability to modify the network interface, like operating the wifi in ad hoc mode. Symbian and iphone OS do not provide this functionality [38] Development Environment The development environments for each of the above mentioned OSs differ as well. The Android development environment is available on Windows, Linux and Macintosh. It can be used in Eclipse, Netbeans [17] or even a text editor with Apache Ant. Windows Mobile is limited to the Windows OS and Visual Studio [17]. Before one can download the software development kit (SDK) for iphone OS, one must first register as a developer with Apple. Secondly, the SDK runs only on Mac OS, which is a deterrent for developers who do not own Mac OS [18]. According to [38] Symbian OS has a sophisticated development platform. Symbian is programmed in C++, and has Symbian specific add-ons like descriptors and a cleanup stack [43]. Symbian also offers a Java runtime environment, but this is restricted to the Java Mobile Device Profile (MIDP), making Symbian Java applications portable, but very limited [38]. It is also reported in [18], that developing applications for Symbian is difficult. Applications for Blackberry can be developed using Java MIDP 2.0 APIs,.Net or RIMs propriety SDK [14] [8]. There is not much available on the Blackberry development environment, although [38], reports Blackberry as 9

16 living up to its reputation for robustness and reliability; it has a rich set of libraries, and allows applications to interoperate seamlessly. Of the above mentioned OSs, Android seems to be the OS that will best suit us. It provides the functionality to be modified as needed, like executing binary files with administrative rights [11], and no licensing is required to use an application. Additionally, it uses the Java programming language, so it provides a familiar programming language interface Wireless Network Management Wireless ad hoc networks are characterized by strong dynamicity, heterogeneity of devices, bandwidth and energy constraints. This makes fixed network management architectures unsuitable. WMN s require new management mechanisms adapted to their functioning. The management tool of such networks must support the following characteristics: [7] Self-organized: Ad-Hoc networks require a management scheme capable of adapting to nodes heterogeneity and movement. Robust: Management should be maintained in a dynamic environment. Low Cost: Ad hoc networks are limited in resources, so the impact of management traffic should be limited. Users expect the quality of service (QoS) from mobile ad hoc networks to be the close to that of wired networks [7]. However, it can be a difficult task providing and managing QoS in an ad hoc network environment [31] due to the dynamics and mobility of the nodes. There are different Network Management Models (NMM) that one can use, each with their respective strengths and weaknesses, each model created to cover a different aspect of an ad hoc network. In general, a NMM should monitor the health and status of the nodes and provide warnings for any abnormalities in the network [37] as well as address the following 5 aspects, regarded as the major functional areas of a NMM by the International Standards Organization's Network Model: [26] Fault Management Accounting Management Configuration Management Performance Management Security Management Fault management is responsible for recognizing, correct and logs errors that occur in the network. Accounting management is responsible for gathering network usage statistics. Configuration management gathers and stores configurations of network devices. Performance management enables the manager to prepare the network for future expansion, and to determine the efficiency of the current network. Security management is used to control access to network resources. In the next section we will look at different network management tools to determine how effective they are in network management and monitoring. 10

17 2.8. Network Management Tools Here we will describe three network management tools: Afrimesh, Meshman and Remesh Afrimesh The Afrimesh project was founded by Antoine Van Gelder, with assistance from the Meraka institute at CSIR. It is described as a simplified dashboard for network management and configuration [12]. The main focus of Afrimesh is to provide a management system to help track and configure nodes in a BATMAN network. Afrimesh is a web-based system, created in JavaScript, and does not need an internet connection to run. It requires a wifi enabled, desktop or laptop pc, running the BATMAN routing protocol. BATMAN allows the pc to become a part of the mesh network, acting as a regular node. Once the pc is part of the mesh network, Afrimesh, through its visualisation module, allows the user to see the network topology overlayed on Open Street Map [40] maps, as pictured below. Figure 2-3: Afrimesh displaying the network topology, for a four node network 11

18 Apart from visualisation, some of the other features that Afrimesh provides for network management are [2]: Visualize live health & traffic information for any mesh node. Keep inventory of your network devices. Monitor the health & usage of your Internet gateway. View network status & log messages in realtime. Online help and live chat support. Customer authentication and management MeshMan MeshMan operates at the network layer, providing a low-overhead solution to network management to cope with the dynamics of a wireless network [6]. MeshMan uses the OpenWRT Linux Distribution on the nodes, designed to be deployed on wireless embedded devices. MeshMan is specifically designed to address the following WMN issues: [6] Robustness of network failure: To diagnose and correct network layer faults, the solution should be independent of the network layer Self-reconfiguration: Failure and addition of nodes should easily be handled. MeshMan makes use of 3 components, common to most NMM s, to achieve its goals: [6] Managing Entity: An application that runs at a management station that controls the collection, analysis and processing of network management information. Managed Device and Agent: The component being managed by the managing entity. It is implemented as a daemon running in the background, collecting information and transferring it back to the managing entity. Network Management Protocol:This defines the communication protocol used between the managing entity and managed device ReMesh ReMesh is a set of tools, instead of a single tool, that when used together provides a NMM. ReMesh hardware runs on the OpenWRT operating system as well, configured for the ReMesh project. According to the ReMesh Project, in order to monitor the network, the network monitoring tool must address the following issues: [15] Resource Constrained Devices Exclusive use of wireless communication Fluctuating link qualities Unfriendly node placement 12

19 To address these above problems, the ReMesh project has developed tools aimed at satisfying the following: [15] Minimal user interaction: Tools should reduce and simplify user interaction. Reliability: Changing parameters should not hamper node communications Low disk footprint: Software on each device should be kept to a minimum Low runtime footprint: The node s priority is to route data in the network, management tools should not be depleting a nodes memory with management queries. Failure resilience: Tools should be able to deal with nodes that suffer from communication failures Comparison of Network Management Tools Network Performance and Bandwidth Monitoring MeshMan uses tcpdump at the mesh manager to collect information on network activity and the tcptrace tool to estimate the bandwidth consumption by management tools [6]. MeshMan does not seem to have a mechanism for monitoring the network performance or total network traffic or even traffic at a particular node; it only monitors management traffic. ReMesh uses two tools for network performance monitoring: the Multi Router Traffic Grapher (MRTG) and Ntop. MRTG is a tool to monitor the traffic on network links. It generates HTML pages, containing images which represent traffic on a link. Ntop is a Web-based traffic measurement and monitoring application. Ntop focuses on traffic measurement and monitoring as well as information for network optimization and planning [15]. ReMesh also implements a system made up of three protocols: A shell script to obtain statistics, a database to store collected data and a web page to display information. The script is executed in the routers, and the data is sent at certain intervals to be stored in the database. The web page can then display this information in the form of graphs [15]. Afrimesh uses the Promiscuous mode IP Accounting package (pmacct) [41] to collect network statistics. A method call is made to each node on the network for their network traffic data. Each node then returns this data. This traffic data can be viewed on the network map, by selecting a particular node Self-Reconfiguration and Fault Management MeshMan uses an adoption daemon to help with network fault management and find optimal routing paths. The adoption process works as follows: A child node periodically broadcasts a Discovery packet, with its path cost to the mesh manager. The node receives packets from neighbouring parents advertising their path costs. The child evaluates the lowest cost path, and then is adopted by the new parent. The parent then sends a DeleteRoute notification to the manager, to inform it of route changes. To cope with node failures, the DeleteRoute message is again used to inform the manager of the lost link [6]. 13

20 ReMesh has not yet implemented a fully working autonomous network configuration scheme. Each node has to be individually configured before they are deployed in the network. The only tool that ReMesh does use to help with network management is Broadcast shell (BShell). BShell is a tool that can automate the process of addressing all nodes, and running desired commands on each node. This helps with failure resistance by keeping a log of errors that could occur in executing commands on a node, and keep the remaining nodes functioning [15]. In Afrimesh, each node has to be manually configured with the nettwork settings before they are deployed. Once deployed, the nodes will configure themselves automatically, based on their routing protocol, BATMAN. To deal with changes in the network topology, nodes in the network periodically check-in with Afrimesh. If a node is missing, Afrimesh displays the last time it checked in, with the node's last known information. Afrimesh does keep logs of network and server messages, and provides a web interface for viewing them, pictured below. Figure 2-4: Afrimesh provides a view of network logs through its web interface Conclusion We have introduced the concept of wireless mesh networks and looked at their uses as well as real world deployments. We've seen that they are a useful technology in areas where there is little or no infrastructure to construct a wired network. We've discussed the Village Telco, and the components of Village Telco that are important to this project. We then had a look at mobile smartphones, and determined that the Android OS will be best suited to our needs. We then introduced network management, and discussed its importance to any network. Network management tools were then discussed, highlighting their differences, their limitations, and determining how effective they are in managing and monitoring wireless networks. 14

21 With this information, we now have some insight into what is expected from network management and monitoring, and which tools are available for use. Chapter 3 Design This chapter discusses the design of the system. We developed software for mobile phones, running the Android OS, to allow the user to monitor and aid in the management of the mesh network. To develop and evaluate the software, we constructed a mesh network testbed of our own using the same hardware and software used by the Village Telco (the Mesh Potato routers and the Afrimesh management system) Scope and Aim of Design The primary function of the Monitoring Component is to gather network information to provide to the other project components, Visualization and Provisioning. To gather network information, Monitoring first ensures that the mobile phone is a part of the network. Once it is recognized as a node, the mobile phone can communicate with other network nodes. It queries all nodes on the network for their information, such as their neighbours, connection strength to neighbours, traffic data and GPS coordinates. Once this information is gathered, it is be available to Visualization and Provisioning. Monitoring also provides updates to the users GPS location (based on the mobile phones GPS), and prompts the Visualization to update the network map according to the users new location in the network. The Monitoring component requires no user interaction. All data received from the network is done autonomously as the user roams the network or when the user explicitly requests for an update. To allow for an uncluttered view of the network, it was decided that we could not display the whole network topology, with all the connections between the nodes, as we are limited to the screen size of the mobile phone. Instead we decided on a localized view of the network. This means that the network topology displayed on the mobile phone would be based on the network node that is closest to the user. The following diagram explains how the system works. In the diagram, to the left we have an example of a wireless mesh network with the Afrimesh server, and on the right, a mobile phone. The Monitoring tool will query all nodes in the network for their information. Based on the GPS location of the mobile phone, we can see that the user (indicated by the mobile phone icon) is located nearest to node A. As a result, node A is the displayed, in green, as the centre node on the phone. Node A's one-hop neighbours (B, C, D, E, F) are then displayed in blue, with their respective connections to A and connections amongst themselves indicated as well. Nodes that are not one-hop neighbours (G, H, I) of the closest node (A), are displayed without their details, or connections to other nodes. Node information will be displayed to the user when a node is selected. 15

22 Figure 3-1: An example of a mesh network, and the resultant display on the mobile phone, based on the users location in the network To enable the mobile phone to communicate with the network, Monitoring would have to ensure that, the phone is connected to the wireless mesh network and that the phone can query the network nodes for their data. Next we will describe the necessary components needed to enable the mobile phone to communicate with the network and retrieve network data System Architecture This component is responsible for the monitoring of the network. Here we describe the hardware and software necessary for the Monitoring component Hardware Mesh Potato: The Mesh Potato (MP) is a wireless router. Once many of these routers are connected, they form an ad hoc network. This ad hoc mesh network is the testbed that we will use to evaluate the application. Afrimesh Server: The Afrimesh server runs Ubuntu 10.04, on a desktop pc, connected to the mesh network. The server is required because the mobile phone cannot retrieve network data directly. The mobile phone accesses the server, and makes network calls 16

23 from the server. When the data is returned to the server, the server then passes this onto the phone. The Afrimesh server also comes with a visualization server. Nodes connect to this visualisation server, and it is through this server that Afrimesh is notified of active network nodes Software JavaScript: The MPs use JavaScript to process queries made to them. Hence, Monitoring will use JavaScript to retrieve information from the MPs. JavaScript Object Notation (JSON): Network data is return from the MPs as JSON objects. Using JavaScript, we will process these JSON objects to retrieve the network data. Village Bus: The MPs have Village Bus installed on them. Village Bus (VB) is the module used to communicate with the MP s on the network, implemented in JavaScript. To access information from the MPs, method calls are made to these JavaScript files. The data is then passed as JSON objects to the caller. BATMAN routing protocol: BATMAN is the routing protocol used by the MPs. Any device that wishes to connect to the network would need to be running this protocol. Android Operating System: The application we are developing will be for Android mobile phones. Android applications are programmed using the Java programming language. This application will communicate with the JavaScript files to access network information Overview of Android OS and Network Testbed Here we will discuss the mesh network testbed we constructed, on which we developed and evaluated the software The Mesh Network Testbed The testbed is an important part of the project, as this is where the Monitoring component was developed on. The network testbed that we constructed consisted of four Mesh Potatoes (MPs) and an Afrimesh server running on a desktop pc. The server and the MPs formed a wireless ad hoc mesh network amongst themselves. Once the network was formed, the mobile phone connected to this network. The network settings used were as follows: Table 3-1: The network settings used on the mesh network testbed Setting Network Mode Extended Service Set ID (ESSID) Value Ad Hoc potato 17

24 Basic Service Set ID (BSSID) 01:CA:FF:EE:BA:BE Channel 1 Subnet Netmask /24 Broadcast Address The Afrimesh Visualization Server The purpose of the Afrimesh Visualization Server is to allow the mobile phone to connect to the network. The server hosts the JavaScript files necessary for network communication. The phone connects to the server using the Secure Shell (SSH) protocol. Once the phone is connected to the server, it loads an HTML file that contains the Monitoring component as well as the Village Bus, JSON and JQuery files, the necessary JavaScript files to communicate with the Mesh Potatoes. The server then processes any network queries made by the phone, and retrieves the network data. It then passes this data to the phone to be processed. The server connects to the network using the D-Link DWA 520 WLAN wireless card. Its specifications are as follows [13]: Table 3-2: Table with the wireless card specifications used by the Afrimesh server to connect to the network Parameter Interface Wireless Standard Supported OS Wireless network configuration Wireless Data Rate Wireless Frequency Range Details 32bit PCI bus IEEE b/g Windows XP, Vista and Ubuntu Ad hoc or Infrastructure mode Up to 54Mbps to GHz The Mesh Potato The Mesh Potatoes are the routers that make up the mesh network. Mesh Potatoes have the Village Bus module installed, which acts as an interface for all the data stored on them, such as their accounting information, connections to neighbours and their GPS coordinates. Any network node that wishes to retrieve data from a Mesh Potato would need to invoke calls to the Village Bus module using JavaScript. The results would then be returned as JSON objects. The hardware specifications of the Mesh Potato routers are given below [34]: Table 3-3: The hardware specifications of the Mesh Potato 18

25 Hardware Processor Memory Wireless LAN Wireless network configuration Details MIPS 4k 180MHz 16Mb Ram 8Mb flash EEPROM IEEE b/g 2.4 to GHz frequency band Omni directional Antenna Ad hoc mode Firmware Linux kernel Customized OpenWrt (Kamikaze) BATMAN routing protocol Asterisk The HTC Legend Android Handset The mobile phone used was the HTC Legend Android Handset. When the network management application is launched, the application first configures the wifi settings so that the phone can connect to the mesh network. Once the phone is on the network, the application SSH s into the server to load the Monitoring component. Once the Monitoring component is loaded, the phone can now access the network data, using the server as a gateway into the network. The details of the phone are as follows [23]: Table 3-4: The hardware and software specifications of the HTC Legend Android handset Hardware/Software Input Processor Memory WLan GPS Internet Connectivity Operating System Web Browser Details Capacitive touch screen Qualcomm 600 MHz 384mb Ram 512mb internal ROM Wi-Fi b/g Supported EDGE and 3G Android OS 2.1 (Eclair) Integrated browser based on the open source WebKit engine 19

26 The following diagram shows how the above components communicate with each other. The interface between the mobile phone and the mesh network is the Afrimesh server, using Village Bus. The mobile phone loads the Monitoring component and Village Bus on the server, and then requests data from the network. Village Bus then queries the MPs individually, and each MP returns their data to Village Bus, which aggregates this data into a data structure (JSON Object). The server then sends this JSON object to the phone. The data is processed in JavaScript and then passed to the mobile phone to be displayed to the user. Figure 3-2: Overview of how the mobile phone will communicate with network nodes 20

27 3.4. Mesh Potato Monitoring Architecture In this section we will discuss the Monitoring architecture pictured below. Figure 3-3: Architecture of the Monitoring component, and how each of the smaller modules interacts with each other Monitoring is divided into two sections which interact with each other. The first section is located on the server. This is implemented in JavaScript, and contains the modules needed to communicate with the network. The second section is located on the mobile phone application, MeshDroid. This is implemented in Java, and contains the modules that run on the Android handset. The reason for splitting the Monitoring component into two sections is that certain sections could only be done in Java, for example File IO, whereas communication with the network can only be done in JavaScript, through Village Bus. We will now discuss each section of Monitoring, and their respective modules JavaScript Monitoring Component The JavaScript section is placed on the server, since it is concerned with network communication. Here we will discuss all its modules. 21

28 Network Data Gatherer This module is responsible for gathering all the needed data from the network, and making it available to other modules, and especially the Visualization and Provisioning components. There are three main data structures, each one an array that contains specific network data. The first contains a list of all the routers IP addresses, their neighbours IP address, and their connections strengths to their neighbours. We will call it allrouters. To get this data, a call is made to Afrimesh, which in turn calls Village Bus with a topology parameter. Village Bus contacts the Visualization server (which runs concurrently with Afrimesh), and the Visualization server returns a list of the routers connected it as JSON objects to Village Bus. Village Bus then returns this data to Afrimesh where it is aggregated into a data structure, containing all the data mentioned above. The second data structure is an array that contains a list of each of the routers IP addresses, their byte count and their packet count. We will call this array nodetraffic. Before this data can be collected, an array of routers on the network must first be populated. The allrouters array described is used for this purpose. Afrimesh makes a call to Village Bus using allrouters and pmacct as parameters. The parameter allrouters tells Village Bus, that these are the routers for which traffic information is needed. pmacct tells Village Bus to make a call to the Accounting server (which also runs concurrently with Afrimesh), to request accounting information. For each entry in allrouters, the Accounting server returns its traffic information. Afrimesh then forms a new array with the each of the nodes information. The third array contains each router s IP address and their GPS coordinates stored as latitude and longitude. We will call this array nodegps. Before this data can be collected, an array of routers on the network must first be populated. The allrouters array described is used for this purpose. The GPS locations are gathered individually (as opposed to the previous arrays, where data structures were returned). Therefore, using allrouters, each IP address is passed as a parameter to Village Bus with a location parameter. Village Bus then addresses the settings on the device to retrieve its GPS locations. The latitude and longitude are returned to Afrimesh as results. MeshDroid then adds the IP address, latitude and longitude as a single object in nodegps. These data structures are periodically re-populated. The automatic updater module in Java prompts for this update every 10 minutes. Alternatively, the user can request the update immediately when required. Once these data structures a populated, their information is available to the other modules. Nearest Node Calculator This module keeps track of the user GPS location (using the mobile phones GPS). It retrieves the phones GPS from the Roaming Manager. Whenever the network map is updated, this module calculates the node closest to the user using the nodegps array. The distance between the phone every node is calculated. The closest node is then selected as the one which has the least distance 22

29 from the phone. The distance (in metres) is calculated using the Spherical Law of Cosines formula given below. d = R cos 1 sin(long2) sin(long1) + cos(long2) cos(long1) cos(lat2 lat1 Where R = metres, the radius of the Earth, and X1, Y1 are the longitude and latitude of the phone and X2, Y2 are the longitude and latitude of a node. The Spherical Law of Cosines was chosen as it is more efficient than the haversine formula, although it loses accuracy over very small distances (less than 1 metre) [9]. The efficiency is important to consider since this module is frequently called, and the phone has limited memory and only a 600MHz. Total Network Traffic Calculator This module calculates the total traffic in the network. It does so by iterating through the nodetraffic array, and adding all the packet count and byte count for all nodes. This information is then passed on to Java, which writes this information to file. This information, once written to file, is then used to plot a graph of network traffic vs. time, which the user can then view. New/Missing Node Calculator This module determines whether a node has been added, or a node has gone missing from the network. It works as follows: Before every update to the network data, the list of node IP addresses in allrouters is copied to another array, called oldrouters. Once allrouters is updated, the new list of node IP addresses is checked against oldrouters. Any entry in allrouters, but not in oldrouters is a new node, and any entry in oldrouters, but not in allrouters is a missing node Java Monitoring Component The Java section is placed on the mobile phone, since its operations cannot be done in JavaScript and are dependent on the Android handset. Here we will discuss all the Java modules. Roaming Manager The Roaming Manager is responsible for keeping the GPS location of the phone up-to-date. It uses the Android OS Location class that provides GPS functionality. To save battery power of the phone, the GPS is only updated every 10 minutes, or every 10 metres that the user moves. This is done through a locationlistener provided by Android. Once the GPS of the phone is updated, this component updates the position of the phone in the Nearest Node Calculator, so that the new location is reflected on the Visualization component. Total Network Traffic Graph 23

30 This module is responsible for drawing the graph of total network traffic vs. time. The data that is written to file by the Total Network Traffic Calculator module is read in, and displayed on a graph. The graph drawing module was adopted from [16]. An example of the graph is pictured below. On the x-axis we see the earliest and latest times. On the y-axis we see the highest, average and lowest packet count. Figure 3-4: Graph displaying the total network traffic (in packets) over time Automatic Updater This module is started when the MeshDroid application is launched. It is a thread that runs continuously every 5 minutes on the phone. It prompts the update of network data by invoking a method call to the Network Data Gatherer module. This concludes our discussion on the architecture of the Monitoring component of the project. Next we will look at the how Monitoring interfaces with Visualization and Provisioning Project Component Interfaces The following diagram shows the interaction between each component of the project, and the interaction between the components and the network. Monitoring communicates with the network, retrieving network data to be passed onto Visualization and Provisioning. Provisioning communicates with the mesh network to retrieve the network settings from the nodes. Using these settings, Provisioning then communicates with nodes that are not yet on the network, but wish to join, to provide these nodes with the correct network settings. 24

31 Figure 3-5: Interaction between each of the project components, and the mesh network Monitoring and Provisioning The only communication that Monitoring and Provisioning have is that Monitoring provides node GPS locations, their traffic data and their neighbour's connection strengths to Provisioning. This data is supplied by the data structures discussed in , under the Network Data Gatherer module. Provisioning does not provide any information to monitoring Monitoring and Visualization Monitoring will report the information of a newly added node or missing node to Visualization. Monitoring will also supply Visualization with node metrics, such as: 1. A node, its neighbours, and their GPS locations and IP addresses. 2. Link quality between a node and its neighbours. This data is supplied using the data structures discussed in , under the Network Data Gatherer module. Visualization does not provide any information to monitoring. 25

32 3.6. Conclusion From the design of the Monitoring component, we can see that Monitoring is primarily responsible for collecting network data, processing this data and then making this data available to Visualization and Provisioning. Monitoring is also responsible for keeping the phones GPS up-to-date, so that the Visualization can draw the correct network map. Chapter 4 Implementation In this section we will discuss significant challenges we faced, as well as problems we encountered Challenges Connecting the Phone to the Mesh Network Connecting the phone to the mesh network was the first and most important step. Without this, the phone would not be able to communicate with any node, or the server on the network. This meant, having to override the network manager, to allow us to change the WLAN interface to ad hoc, with the required network settings and then run the routing protocol, BATMAN, to allow the phone to connect to the mesh network. This required us to do three things: Root the phone, configure the wireless interface and run BATMAN on the phone. Rooting the HTC Legend The first step was to get root access on the phone. This meant, gaining administrative rights to run certain binary files on the phone. This is similar to sudo privileges on a Linux OS. To root the HTC Legend, we had to first find a suitable guide and suitable ROM (a version of Android that is custom made by the community) for this phone, as different Android phones, require different ROMS. The first guide we followed was from the unlockr [22], and we were unsuccessful in rooting the phone. We assume the ROM was incompatible with the HTC Legend. We then tried the rooting guide from android.modaco [24]. This guide provided us with the ROM to flash the phone with, and we subsequently gained root access to the phone. Once the phone was rooted, we could now run binary files that require administrative privileges (like BATMAN), and create an application that can modify the hardware interfaces (like the wifi interface). Configuring the Wireless Interface Once we had root access on the phone, we could manipulate the wireless interface, to switch it into ad hoc mode. The first guide we tried was on modmymobile [10]. It involved modifying the file tiwlan.ini and wpa_supplicant_conf, which are responsible for configuring the wifi interface. However, this did not work. This was because we were modifying files on Android in system directory, which cannot be modified, even with root access. Then, with help from 26

33 Antoine van Gelder, we adopted existing code from the android-wifi-tether project [4]. This is the program that our application, MeshDroid, was built from. We used their configuration script, tether_edify (which we renamed to adhoc_edify), written in the edify language, that configures the wifi interface for ad hoc mode. Secondly, the files tiwlan.ini and wpa_supplicant_conf were modified and supplied with the application (as opposed to editing the copies found on Android). Together, these files allowed us to switch the phone into ad hoc mode, and change the settings of the wifi to that of our testbed. Run BATMAN on the mobile phone Now that we can run the phones wifi in ad hoc mode, with our own settings, we need to run the BATMAN routing protocol on the phone, to allow it to connect to the mesh testbed. For this, we were helped by Antoine van Gelder again. We downloaded the source code for BATMAN, and modified it so that it will run on the Android OS. To embed the BATMAN file into our application, we used the Android NDK [3]. The Android NDK allows developers to embed C and C++ code as part of the application, which is what we needed for BATMAN. Once compiled, BATMAN can be used with MeshDroid. The BATMAN binary, batmand, is included with the MeshDroid source code, and when MeshDroid is installed onto the phone, batmand is copied over. With root access on the phone, MeshDroid can now execute batmand Connecting Mobile Phone to Server One significant problem that we encountered was that the phone could not SSH into the server. Being able to SSH into the server is one of the most important components of MeshDroid, since it cannot function without first establishing this connection. The problem was due to the Android OS not allowing the phone to establish the connection because of its built in firewall. We were able to overcome this by obtaining an SSH program written for Android, which allows MeshDroid to bypass the firewall. We modified the source code of this program to suit our needs Issues Faced Testbed Connectivity We experienced problems connecting our Afrimesh servers to the mesh network. Firstly, a laptop with the Intel 5100 AGN WLAN could not connect to the network, even though it could see the network as being available. This was due to the hardware not allowing us to manually specify the settings for an ad hoc network. As a result, it would not connect to an ad hoc network with our required settings, specified in table 3-1. Secondly, the desktop pc with a D-Link DWA 525 WLAN card could initially connect to the network, but after the MPs were provisioned, and their Afrimesh version updated, the MPs connected using a hidden wireless network. Once this happened, the D-Link DWA 525 WLAN card could not connect to the network. The exact cause of this is unclear. But we noticed that the wireless card would switch to ad hoc mode, but not with our required settings. 27

34 The only server that could always connect to the network was a desktop pc with the D- Link DWA 520 WLAN card. Not having our own testbeds was detrimental to our development, as we could not independently develop our software using our own testbeds. Instead, time was spent emulating network data, so the Visualization and Monitoring could continue to develop their components. The Provisioning component was developed using the testbed, as it requires the Mesh Potato hardware, so it cannot function on emulated data Village Bus on the mobile phone Originally, we wanted the mobile phone to communicate with the network using Village Bus on the phone, without the need for a server. However this was not possible due to time constraints. Although Android OS runs on Linux, it is a distribution different to a desktop Linux, such as Ubuntu Installing the necessary packages that Village Bus needs to operate, such as pmacct, the accounting server and the Afrimesh visualization server would require us to recompile the binary files for the Android OS, much like what we did with BATMAN, as discussed in Section 4.1. To port these applications to Android would require more time. To overcome this problem, we designed our system to allow the phone to communicate with the network using the Afrimesh server, as discussed in Chapter 3, the Design chapter. Chapter 5 Evaluation In this chapter we present the methods used to evaluate the monitoring component and the results obtained. The aim of the Monitoring component was to determine the feasibility of monitoring a wireless mesh network on a mobile phone. As a reminder, our research questions are: 1. Can monitoring a wireless mesh network be effectively achieved on a mobile phone? 2. Can mobile phones be used as an alternative to laptop or desktop pc servers for monitoring a wireless mesh network? 3. What are the limitations with using a mobile phone for monitoring a wireless mesh network? To answer these questions, we set aims for the Monitoring component. Since the Monitoring component is primarily responsible for providing network information, we set out the following aims: 1. Monitoring provides Visualization with up-to-date information about the network. 2. Monitoring identifies that a node has been added or disconnected. 3. Monitoring provides timeous feedback. 4. The MeshDroid application does not deplete the phones battery too quickly, to the point that the application is considered to be unusable. 28

35 5.1. Network Setup The network was created using four Mesh Potatoes and the Afrimesh server. The settings used for the network are described in table 3-2. The network formed was a fully connected mesh network as pictured below. Figure 5-1: The mesh network testbed consisted of a server and four of the beta Mesh Potatoes Once this network was formed, the mobile phone joined the mesh network. The following tests were performed on the mesh network testbed: Test 1: Add MP to the network Test 2: Remove MP from the network Test 3: Network response time Test 4: Time taken for finding the closest node Test 5: Mobile phone battery life Tests 1, 2 and 3 were evaluated on the server, since it is implemented in JavaScript. Tests 4 and 5 were implemented on the mobile phone, using the Java component of Monitoring. 29

36 5.2. Test Descriptions and Results Test 1: Add MP to network Test Description Test 1 determines how long it takes Monitoring to respond to a node being added to the network. This test was conducted as follows: Once 3 of the MPs were connected to the network, another MP was randomly added to the network. The time at which the node was added was recorded. The monitoring software then continuously updated the network data and recorded the time at which it had found that the MP was added. The difference between these time intervals was an indication of long it took the Monitoring to report that the MP was added. This test is important because our application focuses on real-time network monitoring, and as a result we need to provide real time data to the user. We would need to minimize the time taken for the software to respond to a node being added. Test Results Table 5-1: The time taken for a new node to be recognized Test Number Time at which node was powered on Time at which added node was recognized Duration 1 13:49:01 13:51:09 1 minute, 8 seconds 2 13:58:25 14:00:21 1 minute, 56 seconds 3 14:08:18 14:10:09 1 minute, 41 seconds From the time the router is powered on, it takes approximately 1-2 minutes for the monitoring software to detect that a new node has been added to the network. Once the router has booted up, it joins the network. It then connects to the Afrimesh visualization server. Once it is connected, MeshDroid can query Afrimesh and retrieve a list of active routers Test 2: Remove MP from network Test Description Test 2 determines how long it takes Monitoring to respond to a MP gone missing from the network. The test was conducted as follows: Once the network is fully connected, a MP was randomly disconnected from the network. Once a MP is removed, there are two stages before it is recognized as being completely removed from the network. The first is, the MP is recognized as being removed from the network. The second stage is when the MP is removed as a neighbour node from the other MPs connected to it. To record this, we did the following: The time at which the node was removed was recorded. The monitoring software then reported the time at which it had found that the MP went 30

37 missing from the network. Then, the time at which the node was removed as a neighbour from the other MPs was recorded. The difference between these time intervals indicates how long Monitoring took to respond to a MP being completely removed from the network. This test is important because our application focuses on real-time network monitoring, and as a result we need to provide real time data to the user. We would need to minimize the time taken for the software to respond to a MP being disconnected. Test Results Table 5-2: The time taken for a missing node to be recognized Test Number Time at which MP was removed Stage 1: Time at which Monitoring recognized the MP is missing from the network Stage 2: Time at which the missing MP was removed as a neighbour from other MPs Total Duration (1 + 2) 1 13:51:53 13:53:23 13:56:44 4 minutes, 51 seconds 2 14:02:35 14:04:01 14:07:20 4 minutes, 45 seconds 3 14:10:50 14:12:21 14:15:34 4 minutes, 44 seconds From the time a node is disconnected from the network, the monitoring software takes approximately 4-5 minutes to recognize that a MP has gone missing from the network. This time is divided into two stages. The first stage, recognizing that a node has gone missing from the network, takes approximately 1 minute and 30 seconds. This is due to the Afrimesh visualization server. The visualization server is where MeshDroid gets a list of active network routers from. Only once the visualization server recognizes that a MP has gone missing, is it able to inform MeshDroid. The second stage, neighbour MPs recognizing that a MP has gone missing, takes approximately 3 minutes and 20 seconds, after the first stage (approximately 4 minutes 50 seconds since the MP is disconnected). This is due to the BATMAN protocol. The BATMAN protocol periodically broadcasts originator messages as discussed in Section to inform a neighbour node of its existence. Once a neighbour node has been disconnected, it takes neighbouring MPs approximately 4 minutes 50 seconds to delete this neighbour from its routing table. Only once this entry in the routing table is deleted, do the changes reflect on MeshDroid. 31

38 Test 3: Network response time Test Description Test 3 determines the time taken for Monitoring to retrieve network data as the network expands. The test was conducted as follows: First, only one MP was connected to the server. The time taken to retrieve the required data from this one MP was measured. This procedure was then repeated for a network with two, three and finally with all four MPs forming a fully connected network in each case. In each of the above cases, a total of 9 readings were used, and their averages plotted. This test gives us an indication of the time taken for Monitoring to retrieve network data, as the network expands. This is important to note, as we need to know how the network size will affect the performance of the application. Test Results Figure 5-2: Graph depicting the network response times to collect data, as the amount of nodes on the network increases From this graph, we see that the time taken to retrieve network data as the network expands, increases linearly. Keep in mind, that these times include the time to collect data from the server itself. For example, on the graph, when x=1, this means 1 MP and the server. The equation of the graph is approximated by y = 280.8x As we can see, the application will take increasingly longer to respond when collecting data as the network size 32

39 grows. For example, when x=10, it will take an estimated 2.97 seconds to collect data, whereas when x=50 or x=100, it takes an estimated seconds and seconds respectively. These response times are too long to wait for on a phone, especially since the network information is periodically updated Test 4: Time taken for finding the closest node Test Description Test 4 determines how long Monitoring takes to find which node is closest to the user. This was tested with randomly generated network data, on the mobile phone. The times (ms) taken to find the closest node are plotted on the y-axis for increasing network sizes, the x-axis. The data plotted is the average of 15 readings for each of the network sizes. This test is important since finding the closest node to the user is central to the MeshDroid application. We would need to know how well the algorithm runs as the network size increases, so we can better evaluate MeshDroid, as the response time of the phone when updating the network map would be affected. Test Results Figure 5-3: Graph showing how long it takes Monitoring to find the closest node, as the network size grows As we see from the graph, the algorithm scales linearly as the network size increases. These results show that finding the closest node on the mobile phone does not incur a heavy overhead 33