final report wifigenie - university of pittsburghpeople.cs.pitt.edu/~ihsan/genie.pdf · final...

Final Report

WiFiGenieWireless Trekking Guide

Lahore University of Management Sciences [LUMS]

Pakistan Team members:

Nabeel Akhtar [[email protected]] Ihsan Ayyub Qazi [[email protected]] Muhammad Ayaz Karim [[email protected]] Muhammad Shahbaz Khan [[email protected]] Mentor: Dr. Zartash Afzal Uzmi, Ph. D. [[email protected]]

WiFiGenie Final Report Lahore University of Management Sciences

of 21

1. Abstract

Tourism is quickly becoming a rapidly growing industry. Every year, we see an increase in the number of people taking part in excursion trips involving hiking and trekking. Usually, the tourist spots chosen for such trips are remote areas. Such areas lack the basic amenities of electricity and telephone. Consequently, the traditional means of communication cannot be utilized. Therefore, there is an ever growing need of developing effective ways of communication for the tourists who are away from their friends and families. This is where WiFiGenie steps in to take the trekkers and hikers beyond the boundaries of infrastructure dependent communication. The ever advancing technology of today has drastically modified the way in which people communicate with each other. Gone are the days when a computer used to occupy a complete room. With the emphasis now being laid on smaller size and mobility, there is a need to develop new mechanisms with which communication can be established on the fly. Previously, wired networks were the chief connectivity providers. However, with the advent of mobile phones and other wireless equipment, people have started to devote more attention towards the wireless mode of connectivity. Due to the plethora of laptops, palm pilots, Personal Digital Assistants, and Bluetooth gadgets, one can safely assume that wireless medium is becoming the need of the day. WiFiGenie is tailor-made for to fulfill the modern day connectivity requirements.

WiFiGenie is a wireless trekking guide. It aims to provide ubiquitous connectivity such that the hikers can benefit from numerous services which leave the traditional tourist guides far behind. Essentially, we are taking the users of WiFiGenie beyond the boundaries of traditional trekking and venturing into the domain of intelligent electronically guided tourism.

WiFiGenie is beneficial to us at multiple fronts. At one end it facilitates trekkers to plan their treks and make their trips more enthralling. Hikers can share live videos with other people. They can even utilize Voice over IP to have audio interaction with others. On a second front it is immensely valuable to the local tourism promoting agencies. WiFiGenie is an additional service that they can offer to their customers. This would not only make trekking more enjoyable for experienced trekkers, it would also bring more people towards trekking. Its diverse functionality and ease of use takes us beyond the barriers on communication imposed by the unfavorable terrain.


of 21

2. System Overview WiFiGenie System consists of multiple modules that interact with one another to

provide trekkers with capabilities that extend beyond the boundaries of the cumbersome and difficult trekking area. The system comprises of the following modules:

• Genie Tower, • Genie Node, • Genie User Interface and • Database Management Center.

WiFiGenie System Overview Diagram

Database

The Internet

Genie Node

Genie Tower

The Database Management Center

2.1. Genie Tower A Genie Tower has two major components namely, Genie Brain Module (GBM)

and Solar Cells. The GBM is a wireless access point which has been extended to include Ad Hoc routing facility. This facility has been added so that GBMs placed at different locations can communicate with another to form an Ad Hoc Network. This network provides easy connectivity to the trekkers. Furthermore the network is easily scalable and requires minimal configuration. The reason for high scalability of the network lies in the underlying routing protocol used. OLSR is a table driven protocol and its performance is slightly affected as the number of nodes increases. To keep GBMs up and running, they are attached with solar cells to provide the desired power. Solar cells are a viable option as trekking is usually undertaken during the day time. However, this does not limit our


of 21

system to daylight. Keep the energy conservation principles in view we have empowered the solar cells to store extra energy. If required this energy can be used to power the Genie Towers at night.

2.2. Genie Node It is a Personal Digital Assistant (PDA) with an 802.11 interface card and a GPS

receiver. A wireless interface card is required to establish a connection with the GBMs, therefore anyone having a Genie Node can utilize the established Ad Hoc network. A number of applications have been developed for the facilitation and enjoyment of the trekkers. The Genie User Interface provides an easy access to all of the applications. The following applications have been provided:

• Map location module: It determines the locations of the trekkers. • Path Finder: It is essentially analogous to a map; it displays the paths to different

locations. • Eat Healthy: Helps users in locating and choosing nearby spots and restaurants

by providing their addresses and type of cuisine. • Hotel Locator: Assists trekkers in finding a suitable hotel/motel by providing

details about their rating, per night charges, telephone number and address. • Weather Man: Provides the current weather information of the location along

with the forecast of the next three days. • A/V Com module: Allows trekkers to have voice chat using voice over IP

(VoIP). It also allows for audio and video streaming. • Internet Access module: Provides internet access to the trekkers.

2.3. The Database Management Center (DMC) The Database Management Center is the main center of information for the

various applications. A number of servers are located in this center and their function is to store all pertinent information which could be required by the users. For example, they store maps of all tourist spots so that trekkers can find themselves at ease when trekking in unfamiliar territories. Similarly, they also store the current weather information of all locations along with their three day forecast. The DMC is pivotal in providing entertainment as well. It has a vast collection of hit songs. Trekkers can listen to these songs without going trough the hassle of downloading them. All communication takes place via the Ad Hoc network. To keep the user informed and up-to-date with the changing scenarios the relevant information in the DMC is updated periodically.

DMC also has an operator on the WiFiGenie helpline. This helpline can be used to provide help which the Genie Node can not provide. This operator will be connected with the WiFiGenie users through VoIP, so that the Genie Node can be used to contact the operator.


of 21

2.4. System software elements System Software elements can be divided in to three categories based on the type of device it is installed on.

• Database Management Center (DMC): DMC provides assistance to all the users of WiFiGenie in the vicinity. It has servers connected to the Internet so that they may be able to connect the users from remotest areas with the Internet backbone. Moreover servers are also connected with database of maps of the area, list of locations (hotels, restaurants and their information), and intelligent software which can be used to find the shortest-path between locations on the map.

• Genie Tower Module Software: Genie towers are sparsely distributed around the vicinity to provide wireless connectivity to the users. Genie Tower Module will be equipped with 802.11 device which will route the IP packets to and from the Genie node and the Database Management Center. These devices will have Optimized Link State Routing protocol as described in detail in section 3.4.

• Genie Node Software: Genie Node is a PDA given to each user. This node will be the only interface of the Genie User with the outside world. As described in section 3.3, there are multiple IP based services running on this node. These services could be used by the users to find the shortest path from any two places, to find different restaurants and hotels and also to connect with the internet. Software on this device will benefit from both; the services provided by DMC as well as the web.

2.3. Design Methodology Keeping in view the requirements of system engineering which calls for integration of hardware and software as well as analyzing the needs of the system, we adopted the prototyping development model. In the definition phase of the project our stress was on 3 types of definitions:

• Abstract functional requirements: The system is supposed to provide multiple services to trekkers.

• System properties: The multiple services should provide a cheap source of entertainment to the users.

• Characteristics which the system must not exhibit: As the system works on radio-frequency therefore it should not interfere with any other existing service using radio-frequency technology.

In this phase the major stress was on determining the overall objectives which the system would meet. Next in line was the system design phase, which comprised of the following processes:


of 21

System Design DiagramDefine module

interfaces

Specify Module functionality

Identify Modules

Assign requirements to modules

Requirement Analysis

After having gone through the design specifications and analysis the modules were independently developed and test over a period of 20 days. Finally the system integration was done incrementally due to the technical and managerial constraints. Incremental integration process was adopted to reduce the cost of error location. Finally the system was installed and thoroughly tested under its operational environment.

2.4. Novelty and Innovation • Wireless standard 802.11 is typically used for wireless LANs. However,

WiFiGenie uses this Local Area Network device to reap benefits of a wireless Wide Area Network

• Providing connectivity on a large scale usually results in installing huge towers and laying large volumes cables. Most of the times the development is not aesthetically pleasing. Since our system promotes tourism, an aesthetically unpleasant infrastructure becomes self-defeating in nature. WiFiGenie requires no cables to be laid. Even the genie towers use solar cells which are in the spirit of using environment friendly sources of energy. Thus we have designed our system in a manner which does not diminish the tourism appeal of the area.

• WiFiGenie aims to fulfill the dream of ubiquitous connectivity. It uses different gadgets meant for similar purpose, and combines them in such a way that they reap benefits which bellies its size. The greatest of them all is the possibility of pervasive IP connectivity at an affordable price.


of 21

3. Implementation and Engineering Considerations

3.1. User scenario The user scenario below demonstrates one of the many possible circumstances in which WiFiGenie takes us beyond the boundaries of communication and traditional hiking.

Worn-out after a laborious spring quarter Nabeel, Ayaz, Ihsan and Shahbaz decided to embark upon a trip to the mountainous northern areas of Pakistan. Trekking through an unfamiliar territory meant that they required a local guide to plan their daily trips. Therefore, they contacted a famous trekking agency to provide them with an apt guide. To their horror the agency did not come up with a human guide instead they provided them with a cheap, small box; WiFiGenie. The agency claimed that WiFiGenie was better than any human guide and many trekkers were using it to plan their trips to remote, unexplored areas. Since it was much cheaper than any other guides, the friends decided to take it along. The immediate task at hand was to choose a place to visit. Ihsan wanted to undergo a trek to “mountaineers’ nemesis” Nanga Parbat’s base camp. Nabeel was more in favor of the luscious green valley called “the fairy meadows”. After brief argument, indecision prevailed till Ayaz suggested that we should try WiFiGenie’s decision making ability. It asked us to provide some details about the time and duration of the trip and our trekking expertise etc. After consulting its base station’s database and considering our input, WiFiGenie simply ruled out Nanga Parbat’s base camp and the fairy meadows because the path was blocked due to a landslide. It presented a few other options, of which they chose the Hunza Valley as their destination. They downloaded the map of Hunza valley from the base station’s database and commenced their journey towards the valley. When they reached the valley after a 16 hour bus ride, Ayaz started feeling pangs of hunger. Since the other three were also tired, they decided to rest their fatigued feet and satisfy their hunger. Being short on time they needed to find the nearest eating place but they were clueless about the prices, menus and the quality of food served by the local bistros. Nabeel being a big fan of meat products wanted to have an all meat meal. On the contrary, Shahbaz was a vegetarian. They were about to get entangled in an endless discussion about an appropriate eat out place when Ihsan came up with the suggestion to check out what WiFiGenie had to offer. They wanted a restaurant that was cheap and had enough variety of food to satisfy both, meat and veggie lovers. WiFiGenie did it again! It not only highlighted the nearest restaurants on the map but also provided their style of cuisine, price list and the variety of food. Indulged in satiating their hunger they did not notice the fast approaching sunset. As soon as the night fell a new worry enveloped them. It looked as if a new argument would erupt. This time the issue was to look for a suitable place to spend the night in. Exhausted from tiresome traveling, Shahbaz wanted a comfortable sleep that only a five star hotel could have provided. However, Ayaz wanted to save money for future shopping. They did not have the energy and time to go and hunt for the optimal option. Ihsan tried to convince Ayaz and Shahbaz to capitulate and compromise but both refused to budge. They were about to choose separate motels when Nabeel told them to “Have no fear when


of 21

WiFiGenie is here!” It showed them all available, nearby, affordable motels to spend the night in. Next morning brought newer challenges. They had to choose a trek for that day. Ihsan and Ayaz being the daring ones wanted to try out one of the most difficult treks in that area. It was a nightmare for beginners. Therefore, Nabeel and Shahbaz consulted WiFiGenie for a list of beginner level treks and chose an innocuous one. They downloaded the maps of their respective paths from the base station. The maps showed that both treks were more than 10 km long and had very few shelters or resting places. Thus they had to be absolutely sure that the weather would remain calm and conducive to trekking. Hunza valley’s weather is too fickle to trust. So it was up to WiFiGenie to aid them by providing an up-to-date weather forecast. The forecast stated a possibility of showers whereas they could not see even a solitary cloud in the sky. Trusting the Genie they carried along their umbrellas. They were extremely thankful to WiFiGenie when right in the middle of the trek dark clouds suddenly appeared and a heavy downpour began. They consulted WiFiGenie to locate the nearest shelters and sought refuge in them till it stopped raining. Shahbaz suddenly realized that his final exams’ grades were to be uploaded that day and if he had to contest his grades he had 24 hours to do so. He was hopeful of getting an A grade thus decided not to check them till he got back. But Nabeel advised him to use WiFiGenie’s internet service and verify that there were no discrepancies in the grades. Upon checking the grades Shahbaz did find a mistake on the instructor’s part. He e-mailed the instructor to correct the entered marks. Thus WiFiGenie not only helped them plan the trip, its ability to access the internet did what would have been impossible for any human guide. Drained and exhausted from the days trek, they finally decided to hit the entertainment road. Out came the WiFiGenie and the friends started streaming their favorite songs. As the night fell they returned to their motel. Thus a day full of adventure and WiFiGenie’s aid came to an end and they all slept happily realizing the fact that five dollars per night was not a bad bargain for the modern guide-in-the-box; WiFiGenie.

3.2. WiFi Genie

3.2.1. Design Objectives After analyzing the practical requirements of WiFiGenie we have highlighted certain

constraints that our device should meet: • WiFiGenie must have cheap components since it is meant for entertainment. • WiFiGenie must operate in license free ISM band to meet the above objective. • WiFiGenie must be connected with the backbone at all times (extensive coverage). • WiFiGenie must give minimum latency for enjoyable usage. • WiFiGenie must have a user friendly interface. • WiFiGenie must have an I/O module. • WiFiGenie must be light and easy to carry.


of 21

3.2.2. Genie Tower Module (GTM) GTM is placed on well distributed towers across the valley and along the trek. These towers ensure that even if the area is sparsely populated, Genie Nodes can communicate with the backbone to provide all the services to the users.

GTM has two components: Genie Brain Module (GBM) and solar cells. GBM is primarily a processing, routing and communication unit. Hardware of GBM had to fulfill the criteria mentioned in 3.2.1. After an extensive market survey we decided to use Linksys wrt54gs. It is an inexpensive proprietary device which was recently released under GPL. GBM is empowered with a customized firmware which was used instead of the original Linksys firmware as discussed in section 3.4.

Solar cells are used as power source for GBM. Solar cells were used because they are a scalable solution. Whenever the service provider intends to expand his region of his service, he will only need to add more towers at the outskirts of the coverage region. This solution will save him from the hassle of cabling through unfriendly terrain and also from planning for the future from the very beginning.

32 MB RAM 8 MB Flash

200 MHz Processor

Broadcom BCM5325EKQM

Switch

MAC Power Supply 12V - 1.0 Amp

RP-TNC Antenna

Connectors

4 Ethernet + 1 WAN

connector

CPU/MAC One chip

Main board

Genie Brain Module

3.2.3. Genie Node Genie Node uses Compaq iPaq empowered with indigenously developed Genie

User Interface (GUI) firmware described in section 3.3. Genie Node is the actual device given to the users. This device consists of a GPS enabled standard PDA with an 802.11 interface. This interface is used to establish communication with the Genie Tower Modules, which in turn connect Genie Node with the backbone.

3.3. GUI Firmware GUI’s firmware has been especially designed to facilitate trekkers in planning their routine treks. Interface’s ease of use makes it an ideal replacement of a tourist guide and thus takes us beyond the boundaries of conventional trekking and mountaineering.

At the top most level Genie’s user interface has three main modules: a) Map location module b) A/V Com module c) Internet access module


of 21

3.3.1. Map location module WiFiGenie’s user friendliness is epitomized by its simple to operate map location module. Each Genie user has the option of downloading a map of his desired destination. Users can either view the satellite picture or the abstract map of a specific area. The picture below shows a sample map of Aspen Colorado, USA. Users can traverse the map by using the built in arrow keys (encircled on the figure 3.3.1. in red color). They can also zoom-in and zoom-out of the map by using the zoom meter (encircled on the figure 3.3.1. in blue color).

Figure 3.3.1.a

Given below is a satellite picture of the same area in Aspen Colorado, USA.

Figure 3.3.1.b


3.3.1.1. Path Finder Figure 3.3.1.a clearly outlines the roads and streets interconnecting different avenues, parks and other buildings. This facilitates the users to find their way from a given source to a destination. Important tourist spots have been marked with alphabet tags (a few

efuabrtlTtcal

Nepal Restaurant (970) 925-6050 - 0.1 mi NE

Aji's Indian Cuisine (970) 925-6050 - 0.1 mi NE

In & Out House (970) 925-6647 - 0.1 mi W

Les Chefs D'Aspen (970) 925-6217 - 0.1 mi S

Bentley's at the Wheeler (970) 920-2240 - 0.1 mi SW

Daughter Earth (970) 544-3375 - 0.1 mi SE

Takah Sushi (970) 925-8588 - 0.1 mi S

Food Music & Friends Chef Randy Placers (970) 948-2511 - 0.2 mi N

Little Ollie's (970) 544-9888 - 0.2 mi S

of 21

City Market Food & Pharmacy (970) 925-2590 - 0.4 mi SE

xamples are encircled in the igure 3.3.1.b in green color). The ser has a detailed view of the tags s well. Each tag is accompanied y the name of the resort that it epresents, telephone number and he displacement from the current ocation. he path finder has relieved

rekkers from the burden of arrying huge maps and atlases to ssist them in finding the specific ocations.


of 21

3.3.1.2. Eat Healthy Users also have the option to choose a restaurant or any other eating spot from a list of tags. Upon clicking a tag a detailed popup label appears. It mentions the complete address of the place along with its telephone number and Zip code. The most important feature provided in this option is the “directions feature”. Trekkers can ask for directions to reach a specific destination. Our system determines the exact location of the trekker and the using the GPS service finds the most suitable path to the stated destination. The snapshot on the right shows a sample result of a path tracking query.

3.3.1.3. Hotel Locator Hotel Locator option is similar to the Eat Healthy option as far as the main idea is concerned. However, it contains some additional yet utterly essential feature to aid the users in searching a suitable hotel/motel. Hotel locator not only points out the location and path to a particular hotel it also states the rating and per night charges of each hotel. This facilitates the hikers to choose a rest area the suits them the most.

3.3.1.4. Weather Man In places where weather is totally unreliable and predictions of local residents are not trustworthy, WiFi Genie’s “weather man” steps in to keep the trekkers up-to-date with the local weather. It states the current weather conditions along with the prediction for the next five days. It provides detailed data about the temperature, humidity, precipitation chance and wind speed. This option is a leap towards freedom from troubles caused by unexpected weather changes. Thus it takes us beyond the boundaries of limited trekking due to sudden weather change. The figure on the right depicts a sample weather reading of Lahore, Pakistan.


of 21

3.3.2. A/V Com module (AVCM) The audio/video communication module is the hub of inter-user communication. WiFi Genie transcends the barriers that limit GSM communication. It enables trekkers to talk to each other and share live experiences with their peer hikers by using voice over IP (VoIP). Long gone are the days when you needed to carry a separate gadget to listen to music. Now the mountaineers can listen to their favorite songs by streaming them from the main Genie database. Ayaz and Ihsan felt no hesitation in choosing a different trek from Nabeel and Shahbaz as they knew they could always share each other’s experience (refer to section 3.1.). For them WiFi Genie’s video streaming option was like an ever available television.

3.3.3. Internet access module (IAM) Section 3.1 states that Shahbaz was able to email his instructor in time and in the end got the deserving grade (refer to section 3.1.). This would have been impossible without the Internet access module of the WiFi Genie. IAM believes in connectivity for everyone. However, geographical constraints and topographical boundaries restrain us from ubiquitous connectivity. IAM takes us beyond the boundaries of restricted Internet access. It allows the trekkers to surf the Internet from locations which are not even conducive to rudimentary communication world of telephony.

3.4. Genie Brain Module (GBM) Firmware Genie Brain Module is empowered with an indigenously developed firmware. This firmware uses embedded Linux as its operating system. The main task of this module is to route the messages received by and from Genie Nodes and Genie Towers. The routing protocols used in the OSI reference model are depicted below.

Application Layer OLSR is used as an application layer protocol. It runs as a user-space daemon and uses NetFilter to capture

packets from the Networking Software in the Kernel.Presentation Layer

Session Layer OLSR uses UDP as the transport layer protocolTransport Layer

Internet Protocol is used at the network layer and IPv4 Addresses are employed by OLSR. Network Layer

Link Layer 802.11 Standard is used at the Datalink layer. It has

also uses standard encryption and delivery mechanisms.Physical Layer


of 21

3.4.1. Protocols Used in GBM

3.4.1.1. Data Link Layer 802.11g/b (WiFi) is used at the data link layer of OSI reference model. Wireless LAN operates in 2.4 GHz band of ISM band and WiFi certification ensures that WiFi Genie interoperates with other WiFi compatible products. It also provides WiFi Protected Access (WPA) which allows secure, high-speed wireless network access.

3.4.1.2. Network Layer Internet Protocol (IP) is used at the network layer. IP was a need rather than an option as we wanted WiFiGenie to connect to the internet and also reap benefit of other services. IP has grown over the years and is the most deployed network layer protocol around the globe.

3.4.1.3. Transport Layer We used TCP at the transport layer as we expected to have lossy transmission due to wireless medium at the data link layer. TCP is a reliable, connection oriented protocol that caters for lost, reordered and duplicated packets by retransmitting, reordering or discarding them, respectively.

3.4.1.4. Application Layer The Optimized Link State Routing Protocol (OLSR) is a table driven, proactive protocol designed for mobile ad hoc networks. It exchanges topology information with other nodes regularly. The nodes which are selected as multipoint relay (MPR) by some neighbor nodes announce this information periodically in their control messages. Thereby, a node announces to the network that it has reachability to the nodes which have selected it as MPR. In route calculation, the MPRs are used to form the route from a given node to any destination in the network [1]. The protocol uses the MPRs to facilitate efficient flooding of control messages in the network. The larger and more dense a network, the more optimization can be achieved as compared to a normal link state algorithm. The primary reason for using OLSR is that it out performs all other ad hoc routing protocols with respect to Quality of Service. This is because through the periodic exchange of topology information, OLSR is able to recalculate its routes at constant time intervals. With OLSR, nodes have a more accurate view of the network and a more accurate view of the shortest path between a source and a destination. OLSR displays the lowest average end to end hop compared to DSR and AODV ad hoc routing protocols, where the average end to end hop count is defined as the ratio of the total hop counts of all packets successfully received by a destination to the total number of packets received. The ability of OLSR to build paths with consistently lower hops allows a QoS framework to meet lower latency requirements. Additionally, a routing protocol that makes use of


of 21

lower hop counts increases global network performance. When nodes transmit messages in the wireless medium, the data is broadcast in a circular transmission range. During the transmission time the medium surrounding the sender cannot be used by any neighbors. Packets that are sent using paths with needless hops cause unnecessary collisions at the physical layer which highly degrades the performance. [2] Therefore, the path selection mechanisms of OLSR support improved performance of a QoS framework. Hence, we feel that in our settings where the mobility of the Genie towers won’t be great, OLSR would perform the best and would thus ensure minimum delay during audio and video streaming. 3.4.1.4.1. Neighbor Sensing (HELLO messages) Neighbor sensing refers to the process where a node attempts to find information about its neighboring nodes.

Figure 1 – C is the two-hop neighbor of AA

B

C

To gather information about nodes in the neighborhood, each node periodically broadcasts a HELLO message that contains the most recent list of neighbors known to the node, as well as the status of the link (symmetric or asymmetric) to those nodes. Whenever a node receives a HELLO message, it obtains information about its neighborhood. Each node maintains a neighbor table storing information about its neighbors and its two-hop neighbors. 3.4.1.4.2 MPR selection (flooding) After neighbor sensing, a node still does not have enough information to compute routing information to all reachable destinations because it has information only about nodes that are at most two hops away. In this case, MPR-flooding is used to reliably transmit local topological information, in the form of control traffic messages, to all other nodes. Firstly, a set of nodes is selected from a node’s symmetric neighbors. These nodes are called multipoint relays (MPRs). The node that selects this set of MPRs is called the MPR Selector. The function of the MPR is to forward the flooded message from its MPR Selector. To reduce the number of control messages flooded into the network, only MPRs


of 21

generate control messages. Finally, another optimization is done in OLSR; MPRs only declare links with their MPR selectors in their control traffic. All nodes will select their individual set of MPRs independently, using similar or different heuristics to select a minimal set of MPRs. For our selection algorithm, we make use of the following concepts:

• The degree of a symmetric neighbor y of a node x, D[y], is the number of symmetric neighbors y has, excluding the symmetric neighbors of x currently performing the MPR selection and x itself,

• Any symmetric neighbor of a node is chosen as a MPR if that neighbor is the only neighbor of a two-hop neighbor.

Starting with an empty MPR set, the symmetric neighbors that are the only neighbors of some nodes in the two-hop neighborhood are chosen as MPR and placed into the MPR set. The two-hop neighbors are then not considered in the later calculations. The degrees, D[y], of all symmetric neighbors are then calculated for the remaining two-hop neighbors that are not covered. While there are still some nodes in the two-hop neighborhood not covered by nodes in the MPR set, the symmetric neighbor with the highest degree is chosen as MPR. This ensures that the MPR set is optimal, i.e. the resulting number of duplicate message transmission is minimal. The current node is then the MPR Selector of these MPRs Figure 2 illustrates a step-by-step example of MPR selection.

(b)(a)

(c) (d)

Figure 2 – (a) before MPR selection (b) symmetric neighbour that is the only neighbour of some nodes in the two-hop neighbourhood is chosen (c) select symmetric neighbours with the highest

degree (d) after MPR selection [all MPRs selected are in green colour]


The purpose of the second step (Figure 2 (b) selection of symmetric neighbors that are the only neighbors of some nodes in the two-hop neighborhood as MPR) is to optimize the MPR set. 3.4.1.4.3 Topology Control (TC) Message Broadcast and Processing During the topology discovery phase, multipoint relays (MPRs) are used to disseminate topology information through the network. This topology information will allow each node to evaluate routes to destinations in the network. Each node that has been selected as an MPR by its neighbor node will create and broadcast Topology Control (TC) messages to all its 1-hop neighbor nodes. MPRs also retransmit to its 1-hop neighbors the TC messages it received that were created by nodes within its MPR Selector Set. A TC message contains the list of neighbors that have selected the sender node as a MPR and a MPR Selector Sequence Number (MSSN). MSSN is a sequence number that allows nodes to keep track of the most recent topological information. For every new TC message created, this number is incremented to indicate a change in the MPR Selector Set (i.e. list of neighbors that have selected the sender node as an MPR). The format of a TC message is:

MSSN neighbor main address neighbor main address ….

Each node in the network maintains a topology table, in which it recorinformation about the network retrieved from the TC messages receivthe topology table contains information pertaining to the add(T_Dest_Addr) and address of the last hop to the destination (T_Lasttypically indicates that node T_Dest_Addr has selected node T_Last_T_seq is the sequence number of the TC message through which nannounced this information of its MPR Selector Set. Each entry is h(T_time) which indicates the time that this tuple expires and is to be topology table.

When a TC message is received at a node, the message is discardedmessage has already been received, i.e. the MSSN of this message is leof an entry in the topology table in which the T_last is the same as themessage. Otherwise, this message is considered to be the latest and all otable will be removed, i.e. all entries in the topology table whose T_lastoriginator address of this TC message and whose T_seq is smaller thanTC message are removed. Next, for each MPR selector address (i.e. a nselected the sender node as an MPR) listed in this TC message, a neentry is inserted with the MPR selector address as T_dest, originator message as T_last and MSSN of the TC message as T_seq. However if already contains such an entry, the T_time of that entry is refreshed.

List of neighbors that have selected the sender node as a MPR.

of 21

ds the topological ed. Each entry in ress of a node _Addr). An entry Addr as an MPR. ode T_Last_Addr as a holding time removed from the

if another newer ss than the T_seq originator of this lder entries in the

is the same as the the MSSN of this eighbor that have w topology table

address of the TC the topology table


of 21

3.4.1.4.4 Routing Table Calculation The routing table is calculated using the information in the neighbour table that has been determined through the flooding of HELLO messages and the topological information recorded in the topology table that has been determined through the flooding of TC messages. The routing table is updated when a neighbor appears or disappears or when new topology table entries are added or existing topology table entries removed. All destinations in the network with a known route will be recorded in the routing table. Each routing table entry consists of the destination (X_dest), the next hop to the destination (X_next) and number of hops to the destination (X_dist). Shortest path algorithm is adopted during route evaluation. Whenever the routing table is recalculated, all the routing table entries are initially removed. New routing table entries are recorded in the table starting with one-hop neighbors as destination nodes (X_dest). Next, the following process is executed beginning with number of hops, h =1 and each time incrementing the value of h by 1. For each topology table entry, if its destination address (T_Dest_Addr) does not correspond to X_dest of any routing table entry and its address of the last hop to the destination (T_Last_Addr) corresponds to X_dest of a routing table entry whose X_dist is equal to h, then a new routing table entry is inserted with: X_dest set to T_Dest_Addr, X_next set to X_next of the routing table entry whose X_dest is equal to T_Last_Addr of the topology table entry; and R_dist is set to h+1. The execution stops when no new entry is inserted within an iteration of the process.

3.5. Verification and Testing 3.5.1. Database Management Center Testing DMC is based on a server, database and software running on the server. The only device which needed testing was server software. This software has simple implementation of extracting information from database, linearizing it in a pre determined form and finally transmitting it to the Genie node. We will adopt white box testing on most important modules. 3.5.2. Genie Tower Testing Major effort of our team was spend in testing the deployment of Genie towers. We reduced the power of the Genie Tower so that we don’t need great distances for testing and distributed Genie towers over a few hundred meter distances. Initially there were some bugs in the protocol configuration therefore a large chunk of our time was spent in debugging it. All four of us were involved in this testing as physical presence was needed at different places. Software of Genie tower was empowered with well tested Openwrt firmware which was borrowed from the Open Source community.


of 21

3.5.3. Genie Node Genie node was the core of our system therefore much attention was paid during its testing phase. At the initial phase each node was independently tested and then the complete system was integrated and tested. Throughout this phase black box testing approach was used. Desired as well undesired inputs were given to the nodes in order to check whether the system can handle various situations and to establish the robustness and flexibility of the system. 3.6. Cost We have calculated the cost of one Genie Tower to be as follows:

• Linksys WRT54gs 60 USD • 6 feet tall Genie Tower 20 USD • 12V, 1 amp rechargeable power supply 35 USD • Solar cell 25 USD • Omni directional antenna 20 USD

Total cost of the tower is 160 USD Cost of Genie node after reducing the cost of Compaq iPaq is:

• GPS receiver 70 USD • 802.11 card 10 USD

Total cost of Genie node after Compaq iPaq 80 USD

4. Summary We have designed a system with multifarious subsystems such that an entirely

new product emerged without developing much from scratch. This was made possible by long hours of brain storming and analyzing various options available. Initially we started with idea of a project which would take us beyond the boundaries of communication. We discussed many urban projects with our mentor and we even explored the possibility of merging cellular network with the Internet. After a period of 3 months we decided to work on WiFi.

This decision was motivated by the fact that cellular network, like many commercial projects, has seen an exponential growth in research and development. These networks, along with wired data link layer technologies have already changed the way people communicate in a very short time span. Our market survey showed that WiFi was developed with the intention of providing ubiquitous connectivity, and there are many opportunities still begging to be taken up in this field of networking. Soon we found the perfect application of wireless connectivity, in an affluent industry.

We believe WiFiGenie is a substantially marketable idea. Historically tourism has be one of the leading industries in the world. Great amount of revenues are available to the local tourism development corporations around the world. These stats show that WiFiGenie is not just an idea on paper, but it can be easily deployed and can reap benefits.

It is also foreseen that dependability on connectivity will only increase as more and more networks are deployed. People will not consider connectivity as a luxury, but


of 21

will view it like a necessity. This again shows that WiFiGenie coincides with the demands modern man and his adventures.

We foresee that many new services and ideas can be incorporated in WiFiGenie, and we were not able to present them due to lack of time and resources.

• Personal security system can benefit with the deployment of wireless network and

plethora of services offered by the Database Management Center. • Local telephony is still expensive in some countries, and if such networks are

deployed along with Network engineering principals, local population can reap the benefits of VoIP, hot spots and WAN.

• Autonomous networks can be made even in urban regions which would result in multiple applications of this idea. For ex. Schools, workplaces, public parks, shopping malls etc. all such places enjoy mobile users which can benefit from the wireless connectivity.

Sr. Module Dec-Jan Feb-Mar Apr-May Phase I 1 OLSR installation 2 OLSR testing 3 Compiler configuration 4 Interface System Module 5 Package Manager Module Phase II 1 Discovery and Switching Module 2 Integration of System 3 Completion of Prototype 4 Test Bed Setup and Debugging

Completed

Underway

To be completed

Genie Final Report Lahore University of Management Sciences WiFi

of 21

5. References Web Links: [1] http://www.olsr.org. http://openwrt.org/ http://www.linksysinfo.org/ http://maps.google.com http://www.weather.com Books:

1) Roger S. Pressman, Software Engineering A Practitioner’s Approach, Fifth Edition, McGraw Hill, 2001

2) Ian Sommerville, Software Engineering, Sixth Edition, Addison Wesley, 2001 3) Shari Lawrence Pfleeger, Software Engineering Theory and Practice, Prentice

Hall, 1998

http://www.olsr.org/

http://openwrt.org/

http://www.linksysinfo.org/

http://maps.google.com/

http://www.weather.com/

final report wifigenie - university of pittsburghpeople.cs.pitt.edu/~ihsan/genie.pdf · final...

Documents