Report Organization
Background of Data Warehouse and OLAP
Development Environment
Application System Design
Project Result
Conclusion
References
Code Comment Report
Downloads


 

Background of Data Warehouse and OLAP


2.1 Project Background
2.2 Dynamic Source Routing (DSR) Protocol
2.3 Destination-Sequenced Distance Vector (DSDV)
2.4 Optimized Link State Routing (OLSR) Protocol

2.1 PROJECT BACKGROUND

This project is part of the "Wireless Ad Hoc Messenger'' project sponsored by Microsoft. The goal of the project is to develop a Pocket PC Instant Messenger application that enables users to chat with one another in a wireless ad hoc and peer-to-peer (P2P) environment without the need for any pre-existing wireless LAN or WAN infrastructure. Whenever a user with a Pocket PC walks into the ad hoc environment, a "buddy" list similar to that in MSN Messenger's Instant Messaging pops up and the user can chat online with his/her buddies in the infrastructure-less ad hoc network. The report documents the design, implementation and testing of the Pocket PC P2P Instant Massager using Microsoft .Net Compact Framework® and C#® programming language, as well as Microsoft Smart Device Extension® for the .Net platform. The application demonstrates multiple hop communications based on UCP socket API from the .Net Compact Framework. There is no physical infrastructure. All Pocket PCs communicate with each other using Compaq® IEEE 802.11 wireless LAN cards.

Before C# implementation of Pocket PC P2P Instant Messenger, another student of Dr. Chen, Ms. Hongyang Tang, who also worked on this project during Spring semester 2002, designed the user interface of chatting based on the personal Java® running on Pocket PC's Jeode® runtime environment. The application is implemented on the PC and based on the TCP socket API. Since a significant difference exists between PC and Pocket PC platform, as well as the difference between LAN based TCP and 802.11b based UDP, the design and implementation are significantly different from the original interface design. Plus, the original design limited the scope to the interface design, while this report actually designs a working prototype based on the Dynamic Source Routing (DSR) protocol.

Forsberg (2001) described a peer-to-peer wireless Instant Messenger application that uses ViaXML® from Odyssey Software. ViaXML is a product that enables Pocket PCs to expose and call Web Services (including services that allow Pocket PCs to connect directly with each other) called ViaXML. ViaXML enables each Pocket PC to act like both a client and a server, even within the same application. Since ViaXML uses the HTTP protocol instead of IP-based UDP, it cannot broadcast packets to fulfill the requirement of multihop Ad Hoc routing.

Lam (2001) developed a Messenger application "WinChat For .NET" using C# and Microsoft .Net Framework. It is a simple peer-to-peer chatting program that functions very similarly to the WinChat program provided by Windows 2000. It provides all the functionalities that the original WinChat program provides. WinChat For .NET is based on many basic yet powerful techniques provided by the .NET platform, including Multi-Threading, Event-Driven, Windows Form Control and Socket Programming, etc. It uses UDP client/server for local notification, and uses TCP connections to deliver chatting functions. We use some ideas from Lam such as divide the module into "user Interface", "UDP client" and "UDP server" modules, while the projects still have many differences: In out project, we do not use TCP connections; instead, we use UDP class for socket programming. Because of the performance issue, we tried to reduce the thread numbers for the application. The platform base is Pocket PC with .Net Compact Framework, while Lam's project is based on full version of Microsoft .Net Framework and Windows Platform. Most importantly, we implement mutilhop and broadcasting functions.

Wireless Ad Hoc network is a wireless local area network without an infrastructure, in which some of the network devices are part of the network routes themselves. The term "Ad Hoc" has been applied to office or home networks, in which new devices can be quickly added, using, for example, the proposed Bluetooth technology or 802.11b in which devices communicate with the computer and perhaps other devices using wireless transmission.

For our project, we use 802.11b wireless technology for our network support. The 802.11 technology refers to a family of specifications developed by IEEE for wireless Local Area Network (LAN) technology. The 802.11 specifies an over-the-air interface between a wireless client and an access point (in infrastructure mode) or between two wireless clients (in ad hoc mode). We use the 802.11b (Wi-Fi) in ad hoc mode (or peer-to-peer) that provides 11 Mbps transmission (with a fallback to 5.5, 2 and 1 Mbps) between 2 wireless devices in the 2.4 GHz band. We use Compaq® Wireless LAN PC card as the hardware to support our 802.11b wireless Ad Hoc network.

There are many proposals for the mobile ad hoc network environment: Destination-Sequenced Distance Vector (DSDV) is a hop-by-hop distance vector routing protocol requiring each node to periodically to update routing updates; Temporally-Ordered. Routing Algorithm (TORA) is a distributed touting protocol to discover route on demand based on "link-reversal" algorithm; Dynamical Source Routing (DSR) protocol uses source routing with each routed packet carried path information on its header; Ad Hoc On-Demand Distance Vector (AODV) is the combination of DSR and DSDV, with DSR protocol's Route Discovery and Route Maintenance and periodic beacon from DSDV; The Optimized Link State Routing (OLSR) Protocol operates as a table-driven and proactive protocol, and exchanges topology information with other nodes of the network regularly. In this report, we survey three protocols in more detail; Dynamical Source Routing (DSR) protocol, Destination-Sequenced Distance Vector (DSDV) and Optimized Link State Routing (OLSR) protocol. Our design borrows some of the ideas from these existing protocols, although it is DSR-based.

2.2 DYNAMIC SOURCE ROUTING (DSR) PROTOCOL

Accord to Johnson et el. (2001), Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. The protocol is composed of the two mechanisms of Route Discovery and Route Maintenance, which work together to allow nodes to discover and maintain source routes to arbitrary destinations in the ad hoc network. Broch et al (1998) ovulated the performance of DSR protocol and got the conclusion that DSR was very good at all mobility rates and movement speeds, although its use of source routing increases the number of routing overhead bytes required by the protocol.

Diagram 2.1 Network Topology Example

In the case of network topology described in diagram 2.1, Route Discovery is the mechanism that a Node C in the network topology sends a packet to destination Node A through other nodes (B and D) and obtains a routing path from C to A. The first Part of Route Discovery is Route Request, in which Node C floods (broadcasts) packets through the network in a controlled manner and reaches destination Node A. Destination Node A answers the request by sending back Request Reply packet back to original node either through another broadcasting or piggyback to C. Nodes can also retain cache information for the routing.

Route Maintenance is the mechanism by which a Node C detects changes of the network topology such that it can no longer use its route to Node A because of the network status of Nodes B or D has changed. Node C will be notified so that it will use alternative route in its cache or revoke another Route Discovery.

In this report, we implemented the Route Discovery mechanism of the DSR protocol. During route request phase, Node C broadcasts XML-based packet with the original path information stored in the packet as "<Path>C; </Path>" and destination node's ID information as "<DID>A</DID>". When this packet travels through Node B, B checks the destination ID information. Since it does not match with its own ID, Node B re-broadcasts the packet with the Path in the packet updated to "<Path>C; B; </Path>". Node A receives the Packet from B, thus completing the Route Discovery phase. Node A adds itself to the Path information in the packet's Path field "<Path>C; B; A; </Path>". In Route Reply phase, Node A uses the reverse Path information field "<Path>A; B; C; </Path>" and delivers the route path information to C, thus completing the Route Discovery process.

We do not implement Route Maintenance process in this report; instead, the design philosophy can also apply to the design of Route Maintenance. Also, in this report, since each Node does not store route cache information in each node, it has to revoke Route Discovery every time for a new session. We will leave Route Maintenance for future work.

2.3 DESTINATION-SEQUENCED DISTANCE VECTOR (DSDV)

Perkins et al. (1994) presented Destination-Sequenced Distance Vector (DSDV) protocol. It is based on the idea of the classical Bellman-Ford routing algorithm. In DSDV, each node maintains a routing table containing the next-hop information for each reachable destination. Each entry has a sequence number, and if a new entry is given, it prefers the one with the greatest sequence number, or if their sequence is the same, it chooses the metric with the lowest value. Each node advertises an increasing even sequence number for itself. According to Broch et al (1998), a performance evaluation shows that DSDV performs quite predictably, delivering virtually all data packets when node mobility rate and movement speed are low, and failing to converge as node mobility increases.

In this report, during the Nodes' "Awareness" stage, we implemented hop-to-hop routing and periodic beacons as in the DSDV protocol. As described in Diagram 2.1, when Node C joins the wireless Ad Hoc network, it broadcasts packets that carried its information and original Path information as "<Path>C; </Path>" in XML format. When the packet reaches B, B will add its own ID into the Path as "<Path>C; B; </Path>", also add Node C as its "Buddy List" and re-broadcasts the packet. When the packet from B reaches A, A adds C to its "Buddy List" and also adds A's ID into the Path "<Path>C;B;A;</Path>". In this project, all newly detected and reachable nodes are considered as buddies. Since B or D's ID already exists in the Path information of the packet, Nodes B and D will ignore re-broadcasted packets from A. In this way, we can prevent infinite broadcasting among nodes. After the establishment of "Buddy List", Node C will periodically broadcast beacon packets to other nodes to update the status. Because of the processing power of Pocket PC, we design the interval as 10 seconds or 20 seconds to prevent overflow the application with beacon packets.

2.4 OPTIMIZED LINK STATE ROUTING (OLSR) PROTOCOL

Jacquet (2001) proposed an Optimized Link State Routing protocol (OLSR) that is best suitable for large and dense wireless Ad Hoc networks. The protocol is based on the link state algorithm and it is proactive (or table-driven) in nature. It employs periodic exchange of messages to maintain topology information of the network at each node. The protocol uses multipoint relaying technique to efficiently and economically send its control messages. It provides the optimal route in terms of the number of hops, which is immediately available when needed. Laouiti et al (2001) presented a performance evaluation of OLSR mobile ad-hoc routing protocol by a random graph model and a random unit graph model. The random graph model is realistic for indoor or short-range outdoor networks where link fading mainly comes from random obstacles. The random unit graph model is realistic for long-range outdoor networks where link fading mainly comes from distance attenuation. Based on OLSR protocol, Calafate (2002) ported the OLSR implementation to Windows 2000 & Pocket PC.

In this report, we do not implement the OLSR protocol for the Pocket PC project. In the future, we can investigate the work performed by Calafate and investigate the possibility of implementing OLSR protocol for the Instant Messenger application. Based on the same application, we can evaluate the performance for each protocol.

 
Last updated: Thursday, January 16, 2003

Home Project Notebook Contact Us