Alex Song
The purpose of this progress report is to describe the aims of the thesis project and to outline the project plan. The report will discuss the originality of the project through a review of current research. The literature review will present current technologies in the research area and the relevance to the thesis project will be assessed. Current commercial products will also be discussed. Finally the aims and objectives of the project and a project plan will be presented. The project plan will form the most significant part of the report as it will cover the resources required and the techniques to be used for the project as well as a time scale for project milestones and the expected outcomes of the project.
Wireless networking is an emerging technology that allows users to be able access a broad range of information and services while user are mobile. There are two types of wireless networks:- infrastructure networks and ad hoc networks. In infrastructure networks, mobile nodes communicate via base stations which are a part of a fixed wired network. An ad hoc network is a network that is created dynamically without any preexisting network infrastructure. All nodes in an ad hoc multihop network behave like routers, so as nodes move around routes to other nodes in the network will need to be discovered and maintained. Ad hoc networks are very useful in situations like emergency search-and-rescue operations and meetings where people want to quickly share information.
The aim of the thesis project is to create an ad hoc wireless network with mobile handheld devices. In order to achieve this aim research must be conducted on ad hoc multihop routing protocols and a suitable protocol must be chosen for mobile handheld devices. To be able to realize this project within the time frame of the thesis, which is one year, the chosen protocol must be implemented on existing hardware and software platforms.
Mobile ad hoc networks, or MANETs, are fundamentally different to traditional wired networks as wired networks are assumed to be stationary and static. This imposes different design requirement and constraints on routing protocols for MANETs. The following section will discuss various aspects of ad hoc routing protocols and commercial ad hoc products.
There are two categories of routing protocols: table-driven and on
demand-routing. In table-driven routing protocols routing information
is periodically advertised to all nodes so all nodes have an up-to-date
view of the network. Alternatively, on-demand routing protocols only
discovers a new route when it is required to. Hybrid routing protocols
also exist and they try to achieve an efficient balance between both
categories of protocols [3]. Table ![[*]](crossref.png)
shows a comparison between the two methodologies. It is clear that
on-demand protocols are more suited for mobile handheld devices as
network bandwidth and battery power is limited. Some on-demand routing
protocols are discussed in the sections below.
|
Ad hoc On-demand Distance Vector Routing (AODV) is an on-demand version of the table-driven Dynamic Destination-Sequenced Distance-Vector (DSDV) protocol [1]. To find a route to the destination, the source broadcasts a route request packet. This broadcast message propagates through the network until it reaches an intermediate node that has recent route information about the destination or until it reaches the destination. When intermediate nodes forwards the route request packet it records in its own tables which node the route request came from. This information is used to form the reply path for the route reply packet as AODV uses only symmetric links. As the route reply packet traverses back to the source, the nodes along the reverse path enter the routing information into their tables. When ever a link failure occurs, the source is notified and a route discovery can be requested again if needed.
The Temporally Ordered Routing Algorithm (TORA) is a highly adaptive, efficient and scalable routing algorithm [1]. It is a source-initiated on-demand protocol and it finds multiple routes between the source and the destination. TORA is a fairly complicated protocol but its main feature is that when a link fails the control messages are only propagates around the point of failure. While other protocols need to re-initiate a route discovery when a link fails, TORA would be able to patch itself up around the point of failure. This feature allows TORA to scale up to larger networks but has higher overhead for smaller networks.
The Dynamic Source Routing (DSR) protocol is a source-routed on-demand protocol [1]. There are two major phases for the protocol: route discovery and route maintenance. The key difference between DSR and other protocols is the routing information is contained in the packet header. Since the routing information is contained in the packet header then the intermediate nodes do not need to maintain routing information. An intermediate node may wish to record the routing information in its tables to improve performance but it is not mandatory. Another feature of DSR is that it supports asymmetric links as a route reply can be piggybacked onto a new route request packet. DSR is suited for small to medium sized networks as its overhead can scale all the way down to zero. The overhead will increase significantly for networks with larger hop diameters as more routing information will be contained in the packet headers.
TORA is a very good protocol but it is not preferred as it is quite complex and its was designed to scale to large networks while this thesis project is concentrating on small to medium sized networks. The qualities of AODV and DSR appear similar, but studies have shown that DSR has the edge over AODV in terms of number of packets successfully delivered under conditions of high node mobility and movement speed without significant expense in routing overhead bytes resulting from storing the entire route in the packet header [2]. Also simulation results have shown that DSR has an overhead of 1% for moderate movement rates in a network of 24 mobile nodes and in most cases the route lengths are within a factor of 1.01 of optimal [4].
There are many wireless products available but only few of them have
ad hoc capabilities. These products are discussed below. Refer to
Table for a table of features of these
products.
Bluetooth is a technology that promises fast, secure, point-to-point wireless communications over short distances (approximately 10 metres) for devices as diverse as mobile phones, consumer electronics appliances and desktop computers [2]. It uses spectrum in the unlicensed ISM1 band of 2.4 to 2.48GHz. Besides being a hardware standard, Bluetooth defines a protocol stack that allows for hierarchical ad hoc networking in the form of ``piconets'', in which Bluetooth devices form themselves into point-to-multipoint picocells of seven slaves under the control of one master. Multiple piconets in overlapping coverage areas form ``scatternets''. Although Bluetooth has been standardized for quite some time, Bluetooth devices are still not widely available. The Bluetooth devices which are currently available are only point-to-point or point-to-multipoint devices. True ad hoc multihop Bluetooth devices are still yet to be commercialised.
IEEE 802.11b is wireless local area network communications standards
that operate in the 2.4GHz band at data rates of 2 to 11Mbps and distances
of 25 to 300 metres [2]. In an IEEE 802.11 network,
there are two possible modes: ad hoc mode, where all nodes in the
network must be within range of each other, and the infrastructure
mode, in which all inter-node communication must pass via access points.
The ad hoc mode allows for ad hoc network of nodes, but communication
is point-to-point, with no multihop capabilities. Since the IEEE 802.11
standard only defines the physical and data-link layer, it is up to
upper layer protocols to incorporate multihop capabilities. Unlike
Bluetooth, IEEE 802.11b products are widely available.
|
As there are limited commercial products available which can perform true ad hoc multihop networking, there is a need for Piconet II. The Piconet II system will be able to form an ad hoc network on existing hardware and software platforms. The specification for the Piconet II system is to implement the DSR protocol for IPv42 on the Linux operating system. The system will run on x86 based PCs and on ARM3 based Compaq iPAQs using IEEE 802.11b wireless network interfaces. The reason the Linux operating system was chosen was because it was available across many different hardware platforms and the source code is publicly available. Being implemented for IPv4 means that the protocol will be transparent to all applications so existing applications would work without any modifications.
The protocol will be divided into two parts, a packet forwarding part and a routing part. The packet forwarding module will be running in the operating system kernel space and the routing program will be running in user space. The packet forwarding module will have a route table which it looks up in order to forward packets. The routing process will communicate with the packet forwarding module and also update the routing table as routes are being discovered and maintained.
The project plan is organized by tasks in order of expected completion. For each task there will be a start week, an end week and a description of what the task involves.
Start Week 29 - Finish Week 31
To present a 20-minute seminar on the key content of the research. The seminar will describe the scope and relevance of the thesis, the reviewed literature and its relevance to the thesis, the work carried out so far, and the work remaining to be done.
Start Week 27 - Finish Week 38
This is a kernel module for Linux 2.4 and later. It will be using the netfilter architecture of the 2.4 kernel to interface with the existing TCP/IP stack. It is this module which interfaces the routing process to the kernel. The module will be responsible for packet forwarding and communicating with the routing daemon.
The resource required for this task is a computer, the Linux 2.4 kernel, lots of documentation on the Linux kernel and time. Very good coding practices and debugging techniques must be employed as debugging will be very difficult otherwise in the kernel environment.
Start Week 29 - Finish Week 38
This is a user space daemon which communicates with the kernel module to discover and maintain routes. Since is it just a user process it will just use normal system calls to talk to the kernel module. This process must implement the minimum required by the DSR protocol to allow an ad hoc network to be formed. If time allows IPv4 translation support can be added so a mobile device running the DSR protocol can access the Internet through a gateway which will translate between the DSR protocol and IPv4.
The resources required and techniques to be used will be the same as the kernel module.
Start Week 36 - Finish Week 38
A two-page conference paper that captures the relevant and interesting aspects of the project. The conference paper will describe the scope and relevance of the thesis, the reviewed literature and its relevance to the thesis, the work carried out so far, the work remaining to be done, and suggestions for future work.
Start Week 35 - Finish Week 42
The thesis will detail the background, scope and results of the project. The report will describe the scope and relevance of the thesis, the reviewed literature and its relevance to the thesis, and the work carried out. The thesis will be approximately 20000 words or 50 pages.
Start Week 39 - Finish Week 44
Present the results of the project through a demonstration or a poster presentation. A one-page abstract that is in a handout format will be prepared for visitors on demonstration day. It will be brief and informative, and provide a summary of the presentation material.
For the demonstration, it will be ideal to have a graphical traceroute program running on a PC while the mobile device move around. As the routes change, the graphical traceroute program should show that on the screen. It is possible also to demonstrate streaming audio to the mobile devices while the routes are changing.
The expected outcomes for the thesis project are to gain experience being involved in a large project and to develop research and problem-solving skills. By being in a large project, it is expected that various skills like time management and report writing will be further refined. Also it is expected that a deep understanding of networking protocols and the Linux kernel will be attained.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.47)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -index ../main.html -split 0 -local_icons progressreport-one-big.tex
The translation was initiated by on 2001-07-02