Goal: Model the Dynamic Source Routing (DSR) protocol
implementing a rule based inference engine. In our system an agent
is any device on an ad-hoc network that is capable of routing. Our
system will run on an agent and gather knowledge of network
conditions and device energy state information.
Consider an infrastructure-less network consisting of mobile devices
with finite battery capacity. Our system can be designed to maximize
network lifetime as defined as the time until some quantity of network
devices have completely exhausted their power supply.
DSR is an on-demand protocol that updates its routing table on an as
needed basis. This is in contrast to a table-driven protocol typically
employed in a network with infrastructure. DSR is advantageous in a
mobile ad-hoc network because it minimizes the amount of control
data sent from a device and hence its power expenditure to maintain
paths.
------------------ Alex’s outlined protocol --------------------
The Protocol
The protocol will be gossip-based
Nodes will eavesdrop on communications
Flooding will be done in a gossip based way
The protocol will be used in conjunction with an ad-hoc wireless network
The protocol will be used for routing messages among wireless devices
without the use of conventional land-line based routers
The protocol will compensate for the inherent instability of nodes in an ad hoc
network (i.e. nodes disconnecting without due warning)
The protocol will allow for interfacing with various mobile devices
The protocol will utilize a new link cost algorithm
The algorithm will be energy-conscious
Nodes with low energy will be avoided
Energy consumption will be distributed among all nodes in network with
sufficient power.
The algorithm will be factor in loss-ratio
Nodes with high rate of loss will be avoided
The algorithm will take into consideration delay associated with queue length
Nodes with large queuing delay will be avoided
The protocol will maintain an acceptably low-level of latency
The protocol will attempt to maintain the same throughput is currently
implemented
Simulation
Simulation must accurately depict a realistic ad-hoc network with the following
included:
Dropped Packets
Bit Errors on transmission and receipt
Delays due to low power and complete loss of a node
Simulation must be completed multiple times with different parameters
Gossip routing probabilities
Energy limits
Conclusion
The new protocol must extend network life significantly
Network speed and throughput should be affected minimally.
----------------------------------------------------------------------------------
--- Rules to be modeled in our system ---
Fixed aspects: Nodes can broadcast to a fixed distance using a fixed
amount of power
1) Case: Agent has a message and a path to the destination
a) Battery metric is appended to the message
b) Primary path is appended to the message
c) Agent sends message & removes the message from the DB
2) Case: Agent has a message and no path to the destination
a) The Agent broadcasts a Route Request (RREQ) message with
a unique ID
3) Case: Agent has a RREQ and is the destination
a) Agent alters the RREQ by appending the power metric and
unique ID
b) Agent produces a Route Reply (RREP) using the RREQ’s
reverse path
c) Add RREQ path info to DB ***???
d) Agent sends the RREP & removes the RREQ
4) Case: Agent has a RREQ, is not the destination and does not
have a path to the destination
a) Rebroadcast or drop (probability of dropping according to Alex’s
report?)
5) Case: Agent has a RREQ, is not the destination and has a path to
the destination
a) Agent appends its power metric
b) Agent broadcasts the RREQ
6) Case: A node with “low power” receives a packet – doesn’t matter
what kind of message is contained… how do we deal with this?
7) Case: Agent has a new path to a destination
a) Compare against current path to destination
b) Keep the best path (based on power metric…?)
8) Case: Agent senses a change in battery life
a) Agent updates its knowledge
9) Case: Agent has a packet and is the destination
a) Agent sends the packet’s message to the host
10) Case: Agent has a packet, is not the destination and not a
member of the path
11) Case: Agent has a packet, is not the destination and is not a
member of the path
Knowledge Database: (What we store)
Our source ID
Our battery metric
Destination ID
Nodes (list): paths to destination ID’s
Nodes (list): battery metrics of destination ID’s
1. We define our source node as A and our destination node as B
a. Initially, A does not have any routing information
i. A can only send a broadcast
b. To begin, A must send out a broadcast message to locate B
with a unique ID
c. Every device within range of the signal will determine if they
are the destination
i. If this node is the destination
1. Compare the messages path from the source to
stored paths
a. If this is the best path, send the reply in the
reverse path
b. If this is not the best path, send the reply
using the best stored path
2. Send the reply to the reverse path of nodes
ii. If this node is not the destination
1. Determine if they have seen this message before
a. If they have, discard the message
b. If they have not,
i. Append this nodes address to the
message
ii. Re broadcast the message to all
nodes