Ad hoc P2P API

An API for P2P File Transfer Over Mobile Ad hoc Networks

Jose Francisco Amarra Teril Katherine Bilog

College of Computer Studies College of Computer Studies
De La Salle University De La Salle University
Manila, Philippines Manila, Philippines
josef_amarra@yahoo.com terilbilog@live.com

Ericko Dela Cruz Jonah Kemuel Verzosa

College of Computer Studies College of Computer Studies
De La Salle University De La Salle University
Manila, Philippines Manila, Philippines
ecko_delacruz@yahoo.com jkverzosa@yahoo.com

Rhia Trogo-Oblena
Faculty Adviser
College of Computer Studies
De La Salle University
Manila, Philippines
rhia.trogo@delasalle.ph

Abstract—This paper presents an Application Programming
Interface (API) architecture for peer-to-peer file transfer over a
mobile ad hoc network written in Java. The underlying
technologies behind the API are: (1) Wi-Fi to establish the
network and transfer files, and (2) a routing protocol that uses
Ad hoc On-demand Vector (AODV) protocol as a base, married
with concepts from the Delay Tolerant Network (DTN)
architecture and Conditional Max-Min Battery Capacity Routing
(CMMBCR) protocol [1]. This API is designed to handle one file
transfer at a time between Wi-Fi enabled mobile devices.
Ad hoc Networking, Peer-to-Peer (P2P) File Transfer, Wi-Fi,
Multi-hop Networks, Application Programming Interface (API)
I. INTRODUCTION
Over the past few years, mobile devices such as laptops and
mobile phones have a steady-growing number of users. These
gadgets possess greater potential of improvement than before.
Laptops now have the capacity that only desktops could have
before. Mobile phones today include a wide variety of features
and functionalities apart from the usual calling and messaging.
The need for mobility is evident. Even the internet that just
started a few decades ago is now on the palm of each one’s
hand with the use of Wi-Fi. Before the Wi-Fi, mobile phones
make use of file transfer protocols such as the Bluetooth and
the Infrared but both have different concerns and limitations.
Through Wi-Fi, mobile phones and laptops may now access
the World Wide Web and do as much as computers at home
can do – stream videos, download files, and surf the net – in
any place and time with a Wi-Fi enabled area. Adapting to the
internet phenomenon Wi-Fi, mobile phones have been
expanded to accommodate easily the functions and services of
the Wi-Fi. Advantages of this can be the faster speed, more
range, and the ability to implement multi hop approach. With
the fast pace of growing hot spots and technology made-easy
access to Wi-Fi, the need for features incorporating this
technology increases. A particular area of interest is the ability
of file transferring between mobile devices via an ad hoc
network set up through Wi-Fi. The lack of a direct route
between two mobile devices creates a need to employ a multi-
hop approach.
The objective of this research is to abstract the basic file
sharing functions amongst mobile devices employing a multi-
hop approach through Wi-Fi in the form of an application
programming interface (API). This API is designed to handle
one-file transfer at a time between Wi-Fi enabled mobile
devices within a multi-hop ad hoc network. It is assumed that
both parties – the sender and receiver – are familiar with each
other in any circumstance.
 II. THEORETICAL FRAMEWORK
A. Wi-Fi
Wi-Fi is the popular name for the wireless Ethernet
802.11b standard for wireless local area networks. The current
generation of WLANs support up to eleven (11) Mbps data
rates within 100m of the base station [2]. Wi-Fi enabled
devices include personal computers (PC), laptops, mobile
phones, game consoles, MP3 players, and personal digital
assistants (PDA). Anyone can avail of Wi-Fi services provided
that they are within a Wi-Fi hotspot—an area that provides
Internet access via a Wi-Fi network. Wi-Fi can be free of
charge or not depending on the network security. Secure or
password-enabled networks require a user to subscribe to the
network before it can be accessed.
B. Mobile Ad hoc Networks (MANETs)
The term “ad hoc” literally means “for this” or “done for a
particular purpose.” An ad hoc network is, therefore, a
network created for a particular purpose. For instance, a set of
students that have laptops capable of Wi-Fi transmission may
create an ad hoc network among themselves for easy file
transfer. They are temporal, created only if a need arises.
A mobile ad hoc network (MANET) is a pool of mobile
hosts forming an ad hoc network. Because its nodes are
mobile, MANETs rely on wireless connectivity such as Wi-Fi
and Bluetooth. It is self-configuring, easy to deploy, and
decreases dependence on an infrastructure. In this type of
network, the nodes act as both hosts and routers, able to accept
and transmit packets throughout the network. When a node is
within the range of another node, these nodes will be able to
connect to each other. The quality of connection will depend
the distance between nodes.
C. Delay Tolerant Networks (DTNs)
Delay tolerant networking was originally designed for easy
interplanetary networking—an interplanetary Internet.
According to [3], it is “a communication system envisioned to
provide Internet-like services across interplanetary distances
in support of deep space exploration.” Interplanetary
networking is an example of a challenged network—the type of
network DTNs are designed for (e.g. DTNs should be able to
operate given extreme distances like connecting routers on
Earth and Mars, or hold packets until the next hop is available).
Delay tolerant networks may be comprised of multiple routers
as well as multiple networks.
D. Store-and-Forwarding
The store-and-forward approach dictates that when packets
are passed to a node, that node must first store copies whole
messages or fragments of these messages within themselves
before passing on the data to another node. This way, messages
are stored indefinitely within the nodes in the route so that in
case of node failure, there will still be a way to recover the
message to be sent. Furthermore, before nodes forward the
messages, they first verify its integrity. These storage devices
are called persistent storage.
According to [4], DTN routers need persistent storage for one
or more of the following reasons:
1. A communication link to the next hop may not be
available for a long time.
2. One node in a communicating pair may send or receive
data much faster of more reliably than the other node
3. A message, once transmitted, may need to be
retransmitted if an error occurs at an upstream (toward the
destination) node or link, or if an upstream node declines
acceptance of a forwarded message.
E. Ad hoc On-Demand Vector (AODV) Routing Protocol
AODV is an on-demand routing protocol specifically made
for mobile ad hoc networks by C. Perkins, E. Belding-Royer
and S. Das in the Nokia Research Center [5]. Using AODV,
nodes can send messages to other remote nodes by making use
of neighboring nodes as passageways. Within the network, the
algorithm attempts to determine the shortest possible loop-free
route down on nodes in which messages could pass.
Due to limited range of communication, nodes can only
communicate with nodes within their range called neighbor
nodes [6]. HELLO messages are used to perceive and check
connection to neighbors. A node periodically broadcasts a
HELLO message that all its neighbors accept. A link break is
detected whenever a node fails to receive several HELLO
messages [7].
When a source node needs to communicate with an
unknown destination, it transmits a RREQ or a Route Request
message to all of its neighbors [6]. An RREQ packet contains
the source and destination address, lifespan of the message,
and sequence ID. If a node that obtains a RREQ message has a
current route to the destination node or is the destination, it
unicasts a RREP or a Route Reply message back to the source
node. After receiving the RREP, the source then records the
route to its routing table and starts communicating with the
destination using the newly found path. On the other hand, if
the node that obtains a RREQ message is not the destination or
has no current path to the destination, the node rebroadcasts
the RREQ to its own neighbors. In case a link break is
detected or a node stops functioning, a RRER or a Route Error
message is sent to the nodes. Nodes that receive RRER check
their routing tables and erase routes that contain the
unreachable nodes [6].
F. JNetDev
JNetDev is an open source library in Java that enables
developers in handling low level packet manipulations. It
supports the user in developing objects significant to
programming networks which comprises NIC’s (Network
Interface Cards), IPv4 Addresses, Ethernet Addresses, packet
captures and injections and header formats. Essential classes in
the package include jND_NIC Class, which injects packets into
the network and forms a NIC that has its system name,
description, IP Address, MAC Address, gateway and netmask,
jND_IPv4Address and jND_EthernetAddress, whose job is to
wrap and construct addresses from strings, byte arrays and
integers, jND_CaptureSession, which is used to capture
incoming packets and stores them in a packet queue. jNetDev
will be one of the alternatives to UDP socket programming and
would be next to ideal in implementing networking functions
required in the application, especially in the employment of
AODV Protocol algorithm and file transferring [8].
G. JAdHoc
JAdHoc is a implementation of the AODV Protocol in Java.
It complies with RFC3561, and supports both IPv4 and IPv6.
It is employed using Java libraries for networking, graphical
user interfaces, multi-threading, and operating system function
calls. It also makes use of Jpcap, a Java-based class library for
capturing network packets. It has been tested on Linux,
Windows (XP and 2K), and Sharp Zaurus [9].
JAdhoc’s application architecture consists of a class library
that provides the AODV operations. This component
cooperates with the Java class library, Jpcap class library and
the user defined route manipulation class. On the other hand,
JAdHoc’s class architecture assumes a hybrid design pattern
architecture, which includes the Gang of Four Design Patterns
and J2EE Pattern Catalog. In a nutshell, there are objects which
are related to handling the tasks of the AODV Protocol Handler
and Informational Objects which are objects that relate to
holding information. It also uses objects in the Java Collections
class library to handle packet queues, route lists and precursor
lists.
III. DESIGN AND IMPLEMENTATION OF AD HOC P2P API
A. Architectural Overview
Ad hoc P2P API was designed to follow a simple structure
based on the general peer-to-peer Architecture coupled with
JAdhoc, which in turn were based on the leveled approach
used by more common protocols such as UDP. Applications
built under Ad hoc P2P API have three (3) levels, namely: (1)
the Application, (2) Services, and (3) Networking Levels. The
API holds the latter into two (2) layers, leaving the
Application layer to be created by the user.
FIGURE I. AD HOC P2P API LEVELS
The Application Level contains modules that are very
particular to a certain application. These modules may be not
usable to other developers. This level is reliant on the
implementation of the application developer. It includes the
user interface of the application and method calls to the Ad
hoc P2P API.
The Service Level offers peer-to-peer services that are used
by most applications. This includes peer discovery, file
sending and receiving, files handling and representation and
instant messaging for use by numerous applications and
devices. It is here that a common data representation, in the
form of string and raw bytes, is used to help in the sharing and
retrieval of information. It is also in this level that forwarding
of files is included to increase the availability of information.
Lastly, this level has basic monitoring capabilities
implemented through the File Log and Network Log classes.
The File and Network Log classes log messages and the files
that were sent and received by a peer.
The final level is the Networking Level. This layer is, to
some extent, handled by JAdhoc, and was based on the basic
peer-to-peer architecture. This is the backbone of the Service
Level, as its methods depend on the Networking Level to carry
out certain tasks. It is here that actual connections are created
between peers, allowing the exchange of data. The
Networking Level provides two types of connectivity, by
using the Standard Classes in the Ad hoc P2P API which
offers simple peer discovery and interaction and by JAdhoc
which offers the AODV routing implementation in Java.
Note however, that some parts of the application may not
be used by certain Mobile Devices due to the limitations to
their physical capabilities and different platforms.
B. Ad hoc P2P API Components
This section discusses the API components used by the
Application Level, the Service Level and the Networking
Level.
FIGURE II. AD HOC P2P API COMPONENTS
Below is a pseudo-code of how CMMBCR with AODV
and Store-and-Forwarding works:
Step 1: Prompt to send data from the source to the
destination;
Step 2: AODV protocol generates RREQ’s to find the
destination; /* this generates multiple routes to the
destination */
Step 3A: When RREQ reaches a node with a route to the
destination node
Node performs CMMBCR
/* CMMBCR checks: */
if (The battery power of all nodes within the route/s
created) > threshold)
{/*Pl = summation of the total battery consumed
while routing of all nodes of a particular route
Select the route with the smallest Pl*/

The Application Level will contain modules that handle selected_route = where A is a set containing
all possible routes;}
the user interface methods. This level calls the methods used
else
in the Service Level and Networking Level components, this
Step 3B: {/* Select the route with the maximum collective
pertains to the function calls in the lower two levels. The
battery capacity */
Application level also handles the output and appearance of
data and processes used in the certain application. selected_route = where A is a set
containing all possible routes;}
The Service Level concerns itself with the peer discovery Step 4: AODV protocol generates RREP’s following the
and interaction process, establishing routes and maintaining a route chosen by CMMBCR;
connection with them. In this level, the store and forward Step 5A: if(RREP reaches destination)
messaging of DTNs (Delay Tolerant Networks) is also Step 5A1:{/* Store-and-Forward approach */
implemented through file replication and forwarding. Note while(next_hop is not the destination AND next_hop
that the algorithms mentioned will be incorporated for mobile is not missing)
devices. { send DataPackets to next_hop;
current_node = next_hop;
The Networking Level Components execute the basic current_node keeps a copy of DataPackets
operations used by the Service Level and Application Level to until time t;}
send and receive files to and from peers. Step 5A2:
if(next_hop is not the destination AND next_hop is
C. Algorithm missing)
{repeat Step 2 with current_node treated as
The proponents used the Conditional Max-Min Battery
the source node;}
Capacity Routing (CMMBCR) Protocol and plugged it into
else if(next_hop is destination)
AODV to address the issue of battery efficiency. This
{send DataPackets to destination;
algorithm uses the load distribution approach. The goal of this
current_node = destination;
approach is to “balance the energy usage of all mobile nodes
/* destination received the file */}
by selecting a route with underutilized nodes rather than the
Step 5B: else
shortest route,” [7]. The study of [7] further states that this
AODV protocol generates RERR;
approach does not necessarily provide the lowest energy route;
rather, it ensures a longer network lifetime because the nodes
will not be constantly bombarded by routing messages that
deplete battery life.
D. Use Case Diagram
This section provides an overview of how the API will be
used by the developer in implementing peer-to-peer
applications such as the File Sharing applications. End users
will only be able to access the application level functions, but
these functions will depend on functions developed using the
API by the application developer. The API will also provide
the backbone for creating the peer-to-peer network along with
the basic information sharing functions.
FIGURE III. AD HOC P2P API USE CASE DIAGRAM
E. Standard P2P Classes
The Standard P2P is a basic method of networking in the
Ad hoc P2P API. It consists of classes that provide a simple
network protocol that enables peer detection and instant
messaging. The Standard P2P classes’ handles network
communication when individual nodes are in a simple P2P
architecture e.g. connected through a Wi-Fi Internet or a
private ad hoc setup where participants are close to one
another. Some of the features in the standard P2P are also
utilized by the modified AODV algorithm in the Ad hoc P2P
of the API (e.g. Battery Minder) which will be discussed in the
Ad hoc P2P’s section.
Ad hoc P2P’s Standard P2P is implemented using the Java
Networking API and the Java Native Access (JNA). Java
Native Access is an API which provides Java programs
convenient access to native shared DLLs (in Windows) by
solely writing in pure Java code. JNA was used by the
proponents to monitor battery power levels in mobile devices.
Following are the main features of JNA:
1. Automatic Mapping with simple mappings for all
primitive data types from Java to native functions
2. Runs on any platform that support Java
3. Automatic conversion between C and Java strings with
customizable encoding/decoding
4. Customizable mapping from Java method to native
function name, and customizable invocation to simulate C
preprocessor function macros
5. Support for automatic Windows ASCII/UNICODE
function mappings
F. Ad hoc P2P Classes
JAdhoc is an implementation of an AODV protocol
handler as specified in the RFC 3561 in Java by ComNets,
University of Bremen. It supports both IPV4 and IPv6. It is a
Java based implementation, and implemented using Java
libraries for the different functions such as networking,
graphical interfaces, multi-threading and operating system
calls.
It requires the user to install Jpcap, a Java-based class
library for network packet capture. It has been restricted, due
to portability purposes, for Linux, Windows (XP and 2k), and
also Sharp Zaurus. It also requires Winpcap to be installed.
Winpcap is a tool for link-layer network access in Windows
environment. Both tools are open source.
Jpcap has the following features:
1. Jpcap can capture Ethernet, IPv4, IPv6, ARP/RARP,
TCP, UDP, and ICMPv4 packets.
2. Jpcap can be used to develop applications to send and
capture arbitrary packets through a network interface card
and be able to envisage them in Java.
Winpcap has the following features:
1. WinPcap implements all of the classic optimizations
depicted in the packet capture literature
2. WinPcap has a driver that enables the operating system to
give low-level network access, and a library that is used
to easily access the low-level network layers.
IV. LIMITATIONS, ISSUES AND OBSERVATIONS
A. File Sharing
The file sharing mechanism is designed in such a way that
it can handle only one file transfer at a time. The packet
receiver cannot handle concurrent connections from several
peers. A single file transfer process must finished first before
accepting another file transfer request making the file transfer
process less dynamic.
File transfers are limited to 29MB at maximum. The
receivers’ packet buffer consumes a lot of memory when the
file being received is large.
 The file sharing mechanism has a fixed transfer speed. The
datagram packet buffer is fixed at 2082 bytes. From the
proponents’ observations, the results were that the maximum
speed of the transfer per second is also fixed at 2082 x (10 -
20) / 20820 - 41640 bytes or 20 - 40Kbps. It means that it
cannot go higher than 20Kbps, unless the wireless signal is
high. A large file would denote that transferring it would take
much longer.
It is also disadvantageous to use the file sharing over weak
Wi-Fi signals. Packets tend to get lost in this situation,
resulting to more file transfer failures.
B. Network Traffic Dynamicity
The routing scheme of the API is highly sensitive or
responsive to network traffic.
There are periods when some of the peers in the internal
routing table are temporarily disappearing or the whole
routing list is periodically empty.
C. Network Traffic Dynamicity
At the present, the API is only compatible with notebook
and desktop computers and not yet available for mobile
phones. Right now, majority of mobile phones has limited
capabilities and will not able to cater the requirements needed
by the API. The API was designed to run in a complete PC
environment. Future endeavors can make the API work on
mobile phones possible.
D. Standard P2P Classes
Certain port numbers were used by different applications or
some operating system processes on a machine. Since the
developers tested the API in different laptop devices in which
also have different sets of applications, some of the port
numbers were already in use. The Multicast Sender or
Receiver fails to execute that result into malfunctioning of the
peer discovery system where some peers are visible and some
are not. The proponents have decided into port numbers that
are less likely to be used in order to solve the issue.
E. Ad hoc P2P Classes
Determining the exact network card range of a mobile
device is problematical. The developers used black box testing
to check and approximate the range of the mobile devices
installed with the API. They placed the devices in different
locations with precisely the same distance between them. To
solve this, the distance between the devices is set to a standard
2-3 meters so that to ensure the flow of network packets.
Another issue is about the network traffic and signals.
Even though running actively, there are periods when the
mobile devices do not receive routing packets making some
nodes invisible thus, making the internal routing table
temporarily empty. To solve this problem, the developers
created another static duplicate of the routing table which
already contains the maximum entry obtained from the
original routing table to keep track of all the active nodes in
the network. This way, users can easily view and monitor
available peers without relying on the currently running
routing mechanism of the API.
F. General Issues and Observations
The behavior of the nodes and their detection is very much
based on the network interface card used and also the network
it belongs to. The proponents noticed that if the network has
an access point, then packet sending will be easy, but if the
setup is a mobile ad hoc network, it can be a little tricky. The
issue was resolved by spamming several messages, such as
hello and route request, and adapting different threads for
packet listening. The time interval of the messages had to be
changed too. The proponents had to also consider the battery
life of the node since spamming may deplete the power source
available.
Another issue the proponents found difficulty in is the
packet forwarding, which meant that if a node is two (2) hop
counts away, how it could easily send it without having to
spam a lot of messages, telling the middle node to forward
different packets. The precursor’s value, which was part of the
Jadhoc network, stored the information necessary for packet
forwarding. It tells the node which nodes are in the middle of
2 nodes, and which nodes are 2 or more hop counts away. It
helped the proponents since you could tell the main node to
send it to the destination node via the middle nodes available.
After fixing and implementing all the issues, the proponents
successfully transferred files over the network. The size of the
file didn’t matter since the application pieced the file into
smaller parts which was then sent over the network.
V. PERFORMANCE
A. Test Cases
This section discusses the results of the simulations of the
thesis. To recap, there are three (3) parameters for testing:
1. Number of Nodes: The number of nodes in a network.
2. Mortality Rate: The rate in which nodes are removed
from the network due to individual circumstances. Nodes
may be exhausted of energy, turned off, or move out of
the network. This leads to the possibility of network
partitions.
3. Size of the Data: The size of the file being sent from
source to destination.
Each of these factors measure how many successful file
transfers there were per test.
B. Results
This section discusses the results of the simulations of the
thesis. To recap, there are three (3) parameters for testing:
Parameters:
Number of Nodes
- experimental variable
- increases by ten (10) nodes after every subcase
Mortality rate
- experimental variable
- percentage denotes the probability of failure of
each node
- rate increases by 5% every subcase
File Size
- experimental variable
- increases by five (5) nodes after every subcase
Expected results:
- Static: decreasing
- Mobile: decreasing
Actual results:
- Static: decreasing
- Mobile: decreasing
Statistical Correlations:
- Static—Number of Nodes & Mortality Rate &
File Size and Success Rate: -0.977
- Mobile—Number of Nodes & Mortality Rate &
File Size and Success Rate: -0.984
- independently—they have their own attributes such as battery
Analysis: The parameters: number of nodes, mortality rate,
and file size of static and mobile nodes is highly inversely
correlated.
Cause/s: Mortality rate was identified as the parameter that
has the greatest effect on the network, the next being
number of nodes and the one of least weight was file size.
Notice that the graph of any parameter partnered with
mortality rate plummets faster. This particular graph,
however, did not plummet as drastically as the other graphs.
It may be attributed to the increase in the number of nodes
trying to balance out mortality rate. File size may have
contributed to the trend presented by adding an element of
chance.
C. Additional Observations
When nodes are static, the mortality rate dramatically
affects the network stability in a negative way. As nodes die,
possible routes also disappear with them. However, the file
size is not a problem at all. It doesn’t matter how big the data
to be sent is, since the nodes are not moving, the route from
source to destination does not get destroyed unless if a node in
the given route dies.
If the nodes are mobile, the mortality rate does not
dramatically affect the network stability since nodes are
moving, new possible routes become available for the source
to send its file to the destination. However, the file size
becomes a problem if the scenario is that the node receiving a
data packet from another node becomes out of reach or dies.
The number of nodes within the network is also essential.
With more moving nodes present in the network, there are
higher chances that new routes become available for the
source to destination if nodes die compared to a static scenario
wherein the no routes become available as soon as a node in
the route die. Some scenarios show that successful transfers
are also based on luck, given that no nodes die and no nodes in
the route become out of reach.
As a whole, transfer between an ends of the network is
more difficult if all of the factors affecting the network are put
into place (Mobility, Mortality Rate and File Size). Also,
nodes in the center of the network tend to lose battery at a
higher rate than that of the end nodes of the network due to the
fact that those nodes are the one who always relay the many
packets coming to and from the network.
VI. CONCLUSIONS AND RECOMMENDATIONS
The proponents successfully implemented and simulated a
delay-tolerant mobile ad hoc network (MANET) that uses Wi-
Fi. The network implemented in the API and simulated in the
simulator was comprised of mobile nodes, connected by Wi-Fi
in an ad hoc manner. This means that each node in a network
must be capable of receiving and transmitting Wi-Fi signals.
Note that these nodes are independent and behave
capacity, frequency of usage, and may move in and out of the
network on the fly. There is thus an irregularity in a sense that
the nodes show no consistency in behavior and availability.
One may say that there is “consistent inconsistency.” This
chaos defines what an intermittent network is—the kind of
network that the DTN framework was built for. While there
are several aspects of a DTN framework, the proponents saw it
fit to implement store-and-forwarding because it best fit the
algorithm that the proponents tested. In this sense, the
proponents chose to highlight the persistence of the DTN in
transferring files.
The routing protocol chosen for the thesis is AODV. The
protocol, however, was modified because of network
requirements and protocol constraints. The proponents
centered on the problem of battery efficiency because one of
the major disadvantages of AODV is that it is costly in terms
of power consumption. Note that AODV involves a lot of
broadcasting of packets to identify a route and to send data
packets. CMMBCR was chosen because of its simple yet
effective algorithm—it effectively prevents nodes from being
unwisely overused while also considering the quality of the
route chosen for file transfer. The store-and-forward was also
incorporated within the algorithm in a sense that when the
route created is compromised during the file transfer (not
during routing), the last node to receive the full file from the
destination will initiate a route request to find another route to
the destination.
The performance of the algorithm chosen for the API varied
from what the proponents deemed it would. For instance, the
proponents were initially convinced that the algorithm would
yield better results given a static scenario. The nodes were,
after all, more stable that way. This and other factors
constitute that the algorithm is ideal for mobile nodes, as
opposed to the controlled static scenario presented for
comparison purposes. The algorithm is also energy-aware in a
sense that although this approach does not necessarily provide
the lowest energy route; rather, it ensures a longer network
lifetime because the nodes will not be constantly bombarded
by routing messages that deplete battery life. Finally, in the
context of delay tolerant networks, the proponents chose to
implement store-and-forwarding. Note that the store-and-
forward approach dictates that when packets are passed to a
node, that node must first store copies whole messages or
fragments of these messages within themselves before passing
on the data to another node. This way, messages are stored
indefinitely within the nodes in the route so that in case of
node failure, there will still be a way to recover the message to
be sent.
The algorithm, however, has its drawbacks. For one, the
algorithm has difficulty in rerouting when node volatility is
concerned. Also, in terms of battery awareness, what the
algorithm does is to spread out the battery consumed by the
network throughout its nodes. Although this does lengthen
network life, the nodes with greater battery capacity are
compromised. Thus, instead of using CMMBCR as a base for
battery awareness, other protocols might be considered.
Based from the results from the simulator, the parameter
that affects the network stability the most is the mortality rate.
Note the rate of decline of the graphs presented when
mortality rate was used as a parameter for testing. The number
of nodes plays a very important role on a healthy network
because the tests show that when a network gets more dense,
more nodes get to have more routes in their routing table thus
it would be impossible for the source and destination to net get
connected, unless of course if mortality rate is added to one of
the factors. The file size was proven that it does not affect
network stability however; it directly affects the process of
transferring the data but only at a minimum.
The battery efficiency part can still be improved. Aside
from using a threshold in detecting the optimal route, the
algorithm can be modified so that fewer packets can be sent to
and fro the network thus minimizing the battery consumption
of the middle nodes since they are the ones transmitting most
of the packets from multiple RREQs and RREPs and the data
packet itself. Thus lesser RREQs and RREPs are traversing
the entire network. The DTN aspect of the algorithm can be
further improved by adding a waiting time for each node to
send a packet. HELLO packets can also be modified to either
improve efficiency of the file transfer process or the battery
consumption. The longer it takes for the HELLO to be
rebroadcast means that there will be a significant drop in the
battery consumption while making the network more
inefficient and if the HELLO packet takes a shorter time
interval in rebroadcasting, means that the network would be
more efficient but consumes more battery for every nodes.
The file transfer over ad hoc networks was not secure,
especially when sending large files. Packets tend to get lost
occasionally, resulting to connection timeouts. The strength of
wireless signals plays a big role to the success of file transfers.
The API needs improvement on connectivity and security.
Since the API’s file receiver could only accept one file
transfer at a time, improvement could also be done on
concurrency. Extensions are possible since currently the API
could only work on desktops and laptop computers.
Being an API geared for file-transfer, the thesis can be
used for just about anything that requires a mobile ad hoc
network and transferring of files. With some improvement and
extensions, the API framework could be extended for mobile
telephony to provide services such as free text or multimedia
messaging. The mobile phones in question only need software
installed to enable this service. Only phones with this software
will be able to utilize this service. The more people that have
the software in their phones (accounting for density of course),
the better the network will be. The phones, however, need to
be Wi-Fi enabled. This limits the use of this software to third
generation phones. In the near future where connectivity can
be achieved without using wires and cables, the API could
serve as a basis for developing other concepts, projects and
peer-to-peer applications incorporated in mobile ad hoc
networks.
REFERENCES
[1] Yu, C., Lee, B., & Hee, Y. Y. (2003). Energy Efficient Routing
Protocols for Mobile Ad Hoc Networks. [online] Available:
http://academic.csuohio.edu/yuc/papers/energy_routing_final.pdf. (June
27, 2009)
[2] Lehr, W., & McKnight, L. W. (2003). Wireless Internet access: 3G vs.
Wi-Fi?. [online]. Available: people.csail.mit.edu/wlehr/Lehr-
Papers_files/Lehr%20Wi-Fi%203G.pdf. (February 23, 2009)
[3] V. Cerf, S. B. (2007). Delay-Tolerant Networking Architecture. [online]
Available: http://www.ietf.org/rfc/rfc4838.txt. June 27, 2009
[4] Warthman, F. (2003). Delay-Tolerant Networks (DTNs): A Tutorial.
[online]. Available: www.dtnrg.org/docs/tutorials/warthman-1.1.pdf.
(March 28, 2009)
[5] Perkins, C., Belding-Royer, E., Das, S. (2003). RFC 3561 - Ad hoc On-
Demand Distance Vector (AODV) Routing. [online]. Available:
http://tools.ietf.org/html/rfc3561. (June 13, 2009)
[6] Klein-Berndt, L. (2001). A Quick Guide to AODV Routing. [online]. [8] JAdhoc System Manual .(2003). [online]. Available:
Available: www.antd.nist.gov/wctg/aodv_kernel/aodv_guide.pdf. (May http://www.comnets.uni-bremen.de/~koo/JAdhoc.pdf. (July 10, 2009)
30, 2009) [9] jNetDev – An open source library for low level packet manipulation in
[7] Chakeres, I.D. & Belding-Royer, E.M. (n.d). AODV Routing Protocol Java .(2005). [online]. Available:
Implementation Design. [online]. Available: https://ccs1.dlsu.edu.ph/TOOLDEV/Program/Library/. (August 18,
moment.cs.ucsb.edu/pub/wwan_chakeres_i.pdf. (May 30, 2009) 2009)