BANG projects for 2013
Depending on the sophistication level, any of these projects can be adapted for any given level of study. Honours projects are usually programming oriented, MSc projects use a programming effort to collect research data, and PhD projects must explore a novel contribution to the field of Computer Science. Note that Honours teams can also be convened to address a larger programming effort.
Rural community mesh network projects
1. Back end for monitoring a mesh network. Mesh networks are flexible, adaptable and dynamic. Yet they are also complex to monitor and manage. Within the BANG group we have developed good expertise working with mesh nodes configured with the Village Telco firmware (a flavor of OpenWRT using batman-adv as routing protocol) and we are well aware of this complexity. Creating a back-end application entails obtaining and storing the values of the parameters the network manager normally monitors individually in the nodes and sending them to a centralized server when low traffic is the expected in the network. Some parameters should not vary with time (txpower, hw_mode, acktimeout, slottime, etc), or do so in an aggregated way (athstats, ifconfig), while others change dynamically (batctl o, wlanconfig ath0 list, rate_info) and different instances of the value of a given parameter should be stored in memory before sending them to the server. Given the low storage capacity of these routers, the data created to store the values should not exceed the capacity of the device, so the frequency for checking the values and/or mechanisms to compress the data need to be explored. Also, to keep the space consumed to a minimum, a secure mechanism to age the data and remove it once it is on the server needs to be provided. With this back-end in place, the time the network manger expends collecting and aggregating could be severely reduced, also reducing the mistakes by introducing manually the data. The project includes the configuration of a remote access gateway.
2. Front end for monitoring a mesh network. This project provides a front end to the back end project described above. Creating a front-end allows the network manager to quickly visualize the information collected from the different nodes, manually or automatically (see back end description), thereby reducing the complexity. The front end provides a dashboard where the information from nodes, links and routes, contained in the parameters collected, can be easily visualized; as well as mechanisms for user authentication to access the application. It also should provide means to set up alerts if values go over a certain threshold, so the network manager could easily identify active or forthcoming problems. With this front end in place, the complexity of monitoring a mesh network could be severely reduced, and so allowing people with less networking skills, as those that are normally going to manage mesh networks in rural areas, to carry out monitoring tasks.
3. Video performance on mesh potatoes. The mesh potatoes have been designed purely for voice communication, yet they can also be used for video. This project explores video communication impact on the network in terms of bandwidth consumption and affect on quality of service parameters. It can also look at devices, e.g. video conferencing on laptops, tablets and mobile phones connected to the mesh via WiFi in infrastructure and/or ad hoc modes. This project can make use of the monitoring data provided by the monitoring projects described above, and also be used to generate voice and video traffic in order to help generate data and evaluate whether changes made to batman-adv’s configuration actually help or hinder video communication.
4. Mesh audio repository. Since oral communication, as opposed to written, is the norm in rural communities in South Africa, collaborators at UCT and Meraka have built an Audio Repository (AR) on an Android tablet for use by the Tribal Authority (TA) in Mankosi community in the rural Eastern Cape. Since we have now installed a mesh network in this community, we want to migrate the AR onto the mesh, on a variety of devices. The design of the AR system will be provided, and this project implements that design, and could potentially explore its introduction, training, usage and evaluation in the field.
5. Mesh breakout and business model. With a mesh network in place in both the lab (on campus) and in the field (off campus), we are able to provide ‘free’ voice calls on the network. This project sets up a physical gateway for ‘break out’, e.g. via an ADSL and/or 3G Internet connection, and a legal business plan. This could involve interconnect to a VoIP provider, and requires a clear understanding of the underlying technical and legal issues to achieve a realistic business plan for implementing mesh breakout, both for our laboratory and Mankosi mesh networks.
6. Traffic generating mobile client. A number of our projects involve communication to and from a mobile phone using data, either WiFi or 3G, and with both voice and video. This project designs and implements a client to handle multiple protocols, e.g. TCP, UDP, HTTP, FTP, RTP and SIP on the mobile phone that can participate in traffic generation exercises for automated data collection. For example, on the rural mesh project, we’d like to associate a SIP client on a mobile phone to an Asterisk server running on a mesh potato. In order to explore how the network performs under various traffic loads, we’d like to connect the mobile client to a PC-based traffic generator to control a simulated flow of voice and/or video calls to and from the mobile client, and be able to collect network performance statistics.
Deaf community projects
1. Add video notification to Google calendar. For the pharmacy SignSupport project, we need to add a video notification, containing a sign language video, to the calendar to remind a Deaf user when to take a given medication. The notification has two parts: first, a picture of the medication, and second, a sign language video that informs the user how to take it.
2. Authoring tool for SignSupport. Thus far we have designed and built two versions of SignSupport: the first for a Deaf person visiting a doctor, and the second for a Deaf person visiting a pharmacist. SignSupport support essentially presents a scripted conversation flow between a Deaf person and a hearing person around a specific scenario. There is no autmoatic translation. All of the potential sign language videos are stored on the phone. We would like to generalise the tool to be able to handle pre-recorded conversation flows for any given conversation scenario, e.g. visiting the police station, home affairs or library. We would like each scenario to be loaded onto the phone individually, depending on need. The authoring tool is meant to help domain specialists construct the conversation flow and to aid in populating the context with recorded videos and related text.
3. Quality of communication for SignSupport. We need innovative ways to measure how well SignSupport performs for both Deaf and hearing end users. Numerous mechanisms exist to measure real-time voice and video communication, but none are applicable to store-and-forward, or asynchronous, conversation, particularly for sign language. While there is some work being done along these lines at the University of Washington (MobileASL), it is mostly low level codec-oriented. We believe that there is are social factors, alongside user-centred factors, that affect the take-up of tools like SignSupport in addition to physical characteristics of the delivered video content, and want to come up with methods to evaluate them.
4. Android bandwidth pricing calculator. In 2012, we built a mobile packet monitor front end and back end to collect and visualise the data consumed by various applications running on an Android device. This project carries that prototype further, adding support for multiple data plans, a wider array of price visualizations, support for multiple SSID’s on the WiFi interface and calculations to help users decide if they should make a GSM call, VoIP or some sort of breakout, e.g. SkypeOut.
5. Signsupport on low-end phones. We have been building SignSupport for high-end phones, e.g. Android 2.2 and higher, where the entire system runs on the phone. However, another option, to get SignSupport to work on low-end phones would be to take the output of a given information flow and transfer only that flow, e.g. a collection of linked sign language videos, to a low-end phone via Bluetooth.