gradu by jianghongl



Case Study: Tree Routing Protocol

          Robert Löfman

                          Master’s Thesis
                          Supervisor: Kaisa Sere
                          Department of Computer Science
                          Åbo Akademi University
                          Turku, September 2003

In ad hoc networks the nodes can be mobile and therefore need temporary
communication links based on an unguided medium set up in order to meet the current
networking needs. The links are radio channels which access must be coordinated with a
medium access control (MAC) protocol. Nodes can communicate directly with nodes that
are within the reach of the radio signal, also called neighbors. A network layer routing
protocol has to be implemented if we want data packets to be relayed to nodes that are not
in the neighborhood. The network protocols found in “normal” fixed networks do not
work well for ad hoc networks and many ad hoc protocols have been “tuned” to take the
unreliability of radio links into account. TCP must also be redone in order to reach
optimality, for instance if fixed network TCP is run on an ad hoc network it can mistake
link breakage for congestion. In this thesis we will study the protocols at data link,
network and transport layers and then create our own routing protocol called Tree
Routing Protocol (TRP). Lastly TRP is evaluated and the conclusions are given.

Keywords: Ad hoc network, protocol, layer, MAC, IP, TCP, neighbor, node.


1 INTRODUCTION ........................................................................................................... 1
   1.1 Ad Hoc Networks ..................................................................................................... 1
   1.2 Security ..................................................................................................................... 2
   1.3 Power Consumption .................................................................................................. 3
   1.4 Applications for Ad Hoc Networks .......................................................................... 4
   1.5 Problem Description and Overview of Our Work .................................................... 5
2 WIRELESS MEDIA ACCESS CONTROL (MAC) ....................................................... 6
  2.1 The Shared Medium Problem ................................................................................... 7
  2.2 MAC Protocols for Ad Hoc Networks...................................................................... 8
     2.2.1 CSMA / CA........................................................................................................ 9
     2.2.2 MACA................................................................................................................ 9
     2.2.3 MACAW .......................................................................................................... 10
     2.2.4 MACA-BI ........................................................................................................ 11
     2.2.5 PAMAS ............................................................................................................ 12
     2.2.6 DBTMA ........................................................................................................... 13
     2.2.7 MARCH ........................................................................................................... 13
     2.2.8 HAMA ............................................................................................................. 14
     2.2.9 IEEE 802.11b ................................................................................................... 15
     2.2.10 Bluetooth ........................................................................................................ 17
  2.3 Discussion ............................................................................................................... 18
3 AD HOC ROUTING PROTOCOLS ............................................................................. 21
  3.1 The Routing Problem .............................................................................................. 21
  3.2 Proactive and Reactive Protocols ............................................................................ 22
  3.3 Classification of Ad Hoc Routing Protocols ........................................................... 23
  3.4 Ad hoc On-Demand Distance Vector (AODV) ...................................................... 24
     3.4.1 Route Discovery............................................................................................... 25
     3.4.2 Path Maintenance ............................................................................................. 26
  3.5 The Dynamic Source Routing (DSR) protocol ....................................................... 27
     3.5.1 Route discovery process .................................................................................. 28
     3.5.2 Route Maintenance .......................................................................................... 28
     3.5.3 Reflecting Shorter Routes ................................................................................ 29
  3.6 Optimized Link State Routing ................................................................................ 29
  3.7 Discussion ............................................................................................................... 31
4 TCP FOR WIRELESS NETWORKS ............................................................................ 32

   4.1 Mobile IP ................................................................................................................ 32
   4.2 Connecting to the Internet – TCP-I ......................................................................... 33
   4.3 TCP within the Ad Hoc Network – TCP BuS ........................................................ 33
      4.3.1 Domain Name Service ..................................................................................... 36
   4.4 Discussion ............................................................................................................... 37
5 CASE STUDY, TREE ROUTING PROTOCOL .......................................................... 38
  5.1 Definitions............................................................................................................... 38
  5.2 Introduction to TRP ................................................................................................ 39
  5.3 Tree Construction - Routing ................................................................................... 40
  5.4 Forwarding .............................................................................................................. 45
     5.4.1 Forwarding of RQMs ....................................................................................... 45
     5.4.2 Preventing Loops ............................................................................................. 47
     5.4.3 Forwarding of Data Messages ......................................................................... 51
6 PROOFS ........................................................................................................................ 52
7 SIMULATION ............................................................................................................... 55
  7.1 A Technical Description of the Protocol Simulator ................................................ 55
     7.1.1 The Virtual MAC Layer................................................................................... 56
     7.1.2 The Network Layer .......................................................................................... 56
  7.2 Simulation Settings ................................................................................................. 57
  7.3 Results ..................................................................................................................... 60
8 CONCLUSIONS............................................................................................................ 64
  8.1 Summary ................................................................................................................. 64
     8.1.1 Scalability ........................................................................................................ 64
     8.1.2 Connecting to the Internet ................................................................................ 65

SVENSK SAMMANFATTNING ................................................................................... 67

REFERENCES ................................................................................................................. 79

                                                    List of Figures

Fig. 2-1: Four bit chipping code. ........................................................................................ 7
Fig. 2-2: Hidden Terminal. ................................................................................................. 7
Fig. 2-3: Exposed terminal. ................................................................................................. 8
Fig. 2-4: B cannot respond to A because B is deferring. .................................................. 11
Fig. 2-5: C requests data from B with a CTS2. ................................................................. 13
Fig. 2-6: Nodes in a HAMA network with assigned priorities. ........................................ 15
Fig. 2-7: A super frame. .................................................................................................... 17
Fig. 2-8: Classification of MAC protocols. ...................................................................... 20
Fig. 3-1: The zones of LAR. ............................................................................................. 23
Fig. 3-2: Link breakage between node 4 and 5. ................................................................ 26
Fig. 3-3: A partial route where x forwards a packet to Y also heard by node Z. .............. 29
Fig. 3-4: A part of a converging OLSR network. The fat circles are MPRs. ................... 30
Fig. 4-1: Detection of link breakage. Messages are enumerated chronologically. ........... 34
Fig. 4-2: Cwind expansion. ............................................................................................... 34
Fig. 5-1: Views of the network. ........................................................................................ 40
Fig. 5-2: A growing tree.................................................................................................... 41
Fig. 5-3: An interlink between two trees. ......................................................................... 42
Fig. 5-4: A node moves “up”. ........................................................................................... 42
Fig. 5-5: A node moves “down”. ...................................................................................... 43
Fig. 5-6: Change of root. ................................................................................................... 44
Fig. 5-7: RQM format. ...................................................................................................... 46
Fig. 5-8: RQM broadcast. ................................................................................................. 47
Fig. 5-9: Message propagation. ......................................................................................... 48
Fig. 5-10: Incorrect storage time. ...................................................................................... 49
Fig. 5-11: Correct storage time. ........................................................................................ 50
Fig. 6-1: Two shortest paths are found between node 4 and node 1. ................................ 54
Fig. 7-1: 25 nodes in a 400x400 square meter area. ......................................................... 58
Fig. 7-2: 25 nodes in a 350x350 square meter area. ......................................................... 59
Fig. 7-3: 25 nodes in a 300x300 square meter area. ......................................................... 59
Fig. 7-4: Delivery rate of data messages. .......................................................................... 61
Fig. 7-5: RQM rate. ........................................................................................................... 61
Fig. 7-6: Route discovery delay. ....................................................................................... 62
Fig. 7-7: Relayed control messages. ................................................................................. 62


Ad hoc wireless networks are infrastructureless, self-organizing networks of mobile
computers operated by humans. The computers have to detect other computers and
organize a temporary infrastructure for a dynamic network - hence the term
infrastructureless. The temporary infrastructure consists of communication links that
make use of unguided media like the radio waves or infrared light. In addition to
detecting computers close-by they also have to be able to communicate indirectly with
remote computers not in the vicinity. This can be done by letting intermediate computers
relay information between two communicating peers. Because computers are mobile, or
rather the users are mobile, the current infrastructure has to be known in order to be able
to relay information between computers. The goal of ad hoc networking is to provide data
communication anywhere that two or more computer users roam, directly or indirectly, as
a secluded intranet or as a subnet of the Internet if some computer belonging to the ad hoc
network can serve as a gateway. This text will elaborate on software structures, called
protocols that make it possible to provide ad hoc wireless computing.

1.1 Ad Hoc Networks

Wireless multi-hop1 ad hoc networks comprise of lightweight mobile computers, also
called mobile hosts (the synonym node may also be used), equipped with radio enabled
network interface cards to meet communication needs. Every host can communicate
directly with hosts to which the radio signal can be “heard”. These nodes are called the
neighbors of mobile host. Direct communication between neighbors is facilitated by
point-to-point radio links which are also called one “hop” in routing terminology. Radio
frequency bands are a scarce resource and often shared among all hosts, some Medium
Access Control (MAC2) protocol has to be used to coordinate access to the medium. This
can be done in a centralized or distributed fashion. For instance, Bluetooth uses a
centralized scheme where master of a network assigns turns for transmission to slaves.
IEEE 802.11 is a MAC protocol that can utilize both schemes, but in ad hoc networks the
distributed scheme is used. In this scheme nodes contend for transmission turns, but if
more than one host wants to transmit at the same time, a random host is chosen for
transmission. MAC protocols will be discussed in chapter 2 in detail.

In ad hoc networks, mobile hosts serve as user terminals as well as routers, implying that
every host taking part in an ad hoc network has to be prepared to forward other host’s
traffic. Some protocols are more flexible and allow hosts to omit routing functions when
its batteries are showing weakening levels of power. Although a very important issue by
itself, battery consumption is not within the scope of this text and only touched briefly
upon in section 3 in this chapter. As with fixed networks, a routing protocol (OSI layer 3)
  This text talks almost exclusively about multi-hop networks, which means that intermediate hosts must
relay messages between hosts not in direct contact of each other. This is called forwarding.
  The MAC layer is a sub layer of the data link layer, which is the second layer in the OSI model.

has to be used in order to enable forwarding. This protocol performs routing which is a
topology discovering process done by the nodes of the network. The type of the routing
protocol specifies how much of this information has to be up-to-date (i.e. reactive or
proactive). The output of the routing phase is a routing table, which can be consulted as
forwarding is performed. This text will, to the largest part deal with routing protocols.
Chapter 3 discusses existing routing protocols and chapter 5, 6, 7 and 8 presents a routing
protocol developed as a case study for this text and results of the protocol simulation.

As with routing protocols, transport protocols (OSI layer 4) also have to be adapted for ad
hoc networks. For instance, the Internet Transmission Control Protocol (TCP) for fixed
networks has a congestion control mechanism that can misinterpret link breakage for
congestion and slow down data rates in erroneous ways. Transport protocols are usually,
in fixed networks, associated with end-to-end communication without intervention of
intermediate routers, that is, the routers have no transport layer. In ad hoc networks the
intermediate routers (normal nodes) must also participate in the transport layer functions
in order to achieve optimal results [Chandran+98].

Security in wireless networks is a enormously intricate issue, requiring a complete text on
its own, so an in-depth discussion of the issue will be beyond the scope of this text. A
section with a summary of the issue can be found in section 1.2. Different security
concerns exist on different layers, for instance at the MAC layer one has to guard against
eavesdropping and signal sabotage whereas the network layer must see to it that no node
tries to “free-ride” by refusing to forward traffic from other nodes. The network and
transport layers may also implement various encryption techniques to hide sensitive data.
A last issue covered in this introductory chapter includes applications for ad hoc

1.2 Security

In wireless networks, one has to be extra mindful of the fact that everyone that is in the
same area of the network could in theory have access to the medium. If no precaution is
taken to prevent this, an unauthorized user could tune in to the right frequency and
“listen” to data addressed to other users. The schemes that are briefly talked about in
chapter two, called spread spectrum (SS) frequency hopping and SS direct sequence can
prevent unauthorized access of the medium. These techniques see to it that the radio
signal never stays on the same frequency for more than a fraction of a second and then
jumps to another. Only an authenticated receiver is aware of the frequency sequence that
the sender uses, so this can at least in theory block outsiders from “overhearing” secret
data. In addition, because every node serves as a router as well, it is of outmost
importance that a user cannot access data that is being forwarded for another node.

Because it is still possible for unauthorized users to monitor network activity provided
that they know the pseudo random sequence, additional encryption techniques have to be
provided. In 802.11b wireless networks this is provided with an encryption algorithm
called “wireless equivalent privacy” (WEP). The WEP algorithm is, as they put it in

[IEEE99] “reasonably strong”, which means that it is difficult enough to make it
discouraging to try to discover the secret key with brute force methods in practice. WEP
takes care of two things:

                         Encryption of binary data.
                         Protects against unauthorized data tampering.

The process of encryption begins by generating a 64-bit key k, by concatenating a
random 24-bit Initialization Vector (IV) and a 40-bit secret key. The strength of the
encryption correlates to the length of the secret key and the frequency of its alteration. K
is then fed to a pseudo random number sequence generator whose output r is used to
encrypt data d by executing r  d = e. E will have equal length of d plus four bytes
containing a Integrity Check Value (ICV). Thus, both the data and ICV is encrypted by r.
The four byte ICV is generated by a CRC-32 algorithm based on the plaintext data d. The
message that is sent to the other party begins with the IV (as plaintext) followed by e.

For deciphering e, the IV in the message is again concatenated with the pre-distributed3
secret key and feed into the pseudo random number sequence generator to regenerate the
r. The lifetime of the secret key will be prolonged since nodes only have to change the IV
and new keys (k) can be generated. Consequently, executing r  e will generate d.

To implement proper authentication, stations must implement WEP because the same
shared secret keys are utilized in both. This works by requiring that a station wanting to
connect to the network can encrypt a text string generated by a receiver, belonging to the
network. If the requesting station encrypted the random text string so that the receiver can
decrypt it, this means that the requesting station “knows” the secret key and is therefore

1.3 Power Consumption

Devices in ad hoc networks are battery-driven and should be designed to consume as
little power as possible. Energy conserving functions have been implemented at various
levels of software. In fact, functions for controlling the power consumption of hardware 4
have been made available (BIOS interfaces) to operating systems. This means that a
power consumption policy decisions can be made from user space applications. With this
method, a high energy consuming hardware such as displays can be turn off instead of
just invoking a screen saver. Also, different power saving states can be defined,
corresponding to the current level of usage. Intelligent decisions can be made by the
operating system since battery power levels can also be monitored with the help of the
interfaces. For instance, a forced, graceful power-down is important before abrupt crashes
of the computer happen when the battery suddenly becomes depleted.

    802.11b does not specify how the secret keys should be distributed.
    Advanced Configuration Power Interface (ACPI) and Operating System Power Management ( OSPM)

Issues related to saving energy can be found on each protocol layer in ad hoc networks.
At data link layer power can be saved by reducing control messages, which are used to
assert neighbor relationships and synchronization purposes. By reducing the amount of
control messages sent in MAC protocols, power will be saved, but at the expense of
increased delays. When control messages are sent frequently the topology will be also
less known, requiring this to be discovered first, incurring longer delays. The control
messages can also be used to power of the transmitter at suitable points in time (see
PAMAS in chapter 2.2.5). Unsurprisingly, designing good protocols with few packet
collisions will reduce power consumption since retransmission of packets requires

The “control message” argument for MAC protocols also holds for network-level routing
protocols and logically, reactive protocols have an advantage in this sense. Routing
protocols have also been proposed that consider battery level as a routing metric instead
of hops. This kind of protocol discriminates routes consisting of nodes with low battery
levels. Nodes could also be allowed to omit routing functions or forward only high
priority messages [Perkins+01].

1.4 Applications for Ad Hoc Networks

There are numerous applications for ad hoc networks. The obvious one is providing basic
file sharing and supporting ordinary high-level application protocols such as e-mail. It
should be possible to do everything with a mobile terminal that can be done with a fixed
Internet enabled terminals. Ad hoc networks can also provide voice calls with IP
telephony generally implemented at transport/application layer or with built-in support at
lower layers (see WAMIS in section 2.3). Another challenge is how to integrate the ad
hoc network with the Internet. It is easy to see that ad hoc networks can complement
basic wireless LANs and other cell-based networks (i.e. mobile phone systems) when the
terminals cannot reach the base station themselves. In this case, terminals inside the radio
range of the base station can relay the signal to terminals outside the range.

In situations where people come together, like meetings for instance, it can be beneficial
to be able to have instant communication channels to meet application needs. Take a
shopping mall as an example, great savings could be achieved by being able to place
phone calls, not through the network of a telecommunication company, but through
several local devices. The local devices must therefore agree to relay voice packets
originated by someone else.

An application from which the general ad hoc networks actually emerged was the packet
radio system used for DARPA5. This was a radio system that could have intermediate
nodes relay voice packets to destinations that the source did not have direct radio contact.
Ubiquitous computing is a sort of embedded computing that has been envisioned for the
future. Ubiquitous computers are micro computers that can be wearable, monitor the
environment and interact with other embedded devices. This can be very helpful in an
    Defense Advanced Research Projects Agency

emergency situation where an embedded computer has detected abnormalities in a
person’s life signs and calls for help on its own. Furthermore, rescue personnel have
recognized the advantages of ad hoc networks. Imagine a distant location where there is
no mobile phone system coverage. Here rescuers could continue to communicate if an ad
hoc network is formed at the site. In the future it is likely that more and more ad hoc
terminals will be embedded in ordinary appliances to enable exchange of information on
a totally new level.

1.5 Problem Description and Overview of Our Work

The main objective of this thesis is to obtain a thorough understanding of problems
related to designing ad hoc network protocols, both in theory and in practice. The
theoretical part was done by studying related work in chapters 2, 3 and 4. These include
research of protocols used at data link, network and transport layers of the OSI model. As
computer scientists, the problems at the network and transport layers interested us most.
The main issue at the network layer is how to build routing tables and forward packets
with the least amount of overhead and delay (see section 3.1 for more about the routing
problem). The transport layer in ad hoc networks, as in fixed networks, provides end-to-
end communication channels, but has to be modified to take link breakage into account.

The practical part culminated in a routing protocol which we developed in order to
understand which factors have to be taken into account when developing network
protocols. Moreover, the protocol is evaluated with the output of a simulator running the
protocol. The protocol developed was called Tree Routing Protocol (TRP) and came from
an idea to provide a way for nodes to make smarter forwarding decisions when
discovering routes, by at least knowing a subset of nodes to which the discovery message
does not have to be forwarded.


The MAC layer is concerned with providing a direct communication channel between
terminals through a shared medium. The medium is an electromagnetic (or infrared)
frequency band on which data is transmitted. In digital radio data communication, a
channel does not necessarily have to be a completely separate frequency, but can be a
time slot on a shared frequency (different division multiplexing methods are discussed
later). Choosing the frequency is not always an easy task since different countries might
not always agree on which frequency should be used. Many countries allow unlicensed
short-range radio transmission on a frequency band called Industrial, Scientific and
Medical (ISM, 2.4 - 2.4835 GHz). This is the kind of communications link that will be
assumed throughout the rest of the text, we will not consider infrared links since these are
unpractical in ad hoc networks. When data is transmitted on a frequency, a scheme for
resisting interference (i.e. from microwave ovens, wireless mice and such), unauthorized
reception and transmission has to be used6. Although we talk about point-to-point links
between neighbors, it is still a broadcast signal sent through the air that can be overheard
by any node within radio range. So, the MAC protocol should provide timely access of
the point-to-point links (see hidden terminal problem in section 2.1) and the transmission
technique has to allow many physically different wireless networks to operate at the same
time in the same geographical area.

Originally developed for military purposes, a transmission technique called spread
spectrum solves the problem of heterogeneous networks operating in the same area.
There are two ways of spreading a signal over a wider spectrum: the first one is called
“frequency hopping” and the second “direct sequence”. As we will see, this minimize the
risk that two signals will be at the same frequency at the same time long enough to ruin
the data that they carry. With frequency hopping both the transmitter and the receiver
agree on a seed, which is fed to a pseudo random (so-called because if the seed is known,
the numbers it generates is also known) number generator whose output is used as the
next frequency by both devices in synchronization. Every frequency is used for a small
interval making it impossible to “overhear” larger portions of data traffic and decreasing
the risk of different wireless networks interfering with each other.

In direct sequence the spreading achieved by combining a pseudorandom sequence of bits
with the data bits, by using exclusive or. In order for this to work the pseudo random
sequence has to be clocked at faster pace than the data signal. For example, if there are
four transitions (four chips) in the pseudo random signal during the bit time of one bit in
the data signal then one data bit will be encoded with four transitions. This is called four-
bit chipping code. The resulting signal will thus seem like noise to other terminals but the
receiver that knows the pseudorandom code and can remove the noise. Since every bit is
represented with many chips, there is redundancy at every data bit making the signal
more resilient against interference. See figure 2-1 for an example.

    The transmission technique is specified at the physical layer.

                                Fig. 2-1: Four bit chipping code.

In this chapter we use the word terminal instead of node for variation. In older literature
the word terminal is used, for instance the description of the classical problem of hidden
terminal. When describing protocols in the following chapter the term initiator will be
used when referring to the terminal that originally initiated communication between two
terminals. If it is clear from the context, the term sender is used instead of initiator and
the receiver is the terminal that the initiator originally addressed. Also, half duplex radios
are assumed, that is, these can either transmit or receive at one point in time.

One of the most important factors to take into account in a MAC protocol is how
effective reuse of the medium it provides. If, for instance, one terminal’s transmission
blocks the neighbor’s transmission then the throughput of the networks will drop.
Another important thing is whether the protocol can provide collision-free operation.

2.1 The Shared Medium Problem

Problems in wireless computer networks with a shared medium (frequency band) have
been identified. For instance, a problem called “hidden terminal” appears when at least
three nodes (A, B and C) are operating close to each other, so that A and B, and B and C
are within radio range. If A and C sends to B at the same time, the data received at node
B will be corrupt. This can happen because A and C are “hidden” from (cannot sense)
each other, this is shown in figure 2-2.

                  Radio range

                                  A            B             C

                                   Fig. 2-2: Hidden Terminal.

A related problem called “exposed terminal” could arise in a scenario depicted in figure
2-3. Because many MAC protocols inhibit transmission when transmission of another
terminal is detected, node A will not be able to transmit to any node when B is
transmitting to C. This is not correct since A could transmit to any terminal other than B
and C that is within its range without spoiling the reception at terminal C.

                            A           B             C

                                  Fig. 2-3: Exposed terminal.

2.2 MAC Protocols for Ad Hoc Networks

A number of schemes for accessing a shared medium have been proposed so far. An
overwhelming portion of MAC protocols use at least two short control messages for
reservation of the medium in order to combat hidden/exposed terminal problems. The
transmission reservation is done by transmitting a “Ready To Send” (RTS) and a terminal
accepting this request answers with a “Clear To Send” (CTS). Every terminal that
overhears the RTS or the CTS will defer from transmitting during a specified time in
order to avoid collisions. If a collision does occur, this is detected when certain amount of
time has elapsed without receiving an acknowledgement for a packet. After a collision,
protocols generally retransmit the packet that collided. This cannot be done instantly
because then the packets sent by two or more terminals would collide again. This can be
helped by backing off a random amount of time between 0 and the number of collisions
for the same packet experienced so far times a backoff slot time (depending on the
physical characteristics of the network). This method is called binary exponential backoff

We will now examine a number of propositions that are more or less based on this type of
communication. These are CSMA/CA, MACA, MACAW, MACA-BI, PAMAS,
DBTMA and MARCH. After that, a new protocol called HAMA is examined. Sections
2.2.9 and 2.2.10 contain specifications of MAC protocols that have been implemented in
two wireless networks, called IEEE 802.11b and Bluetooth. All of these protocols solve
the shared medium problem in different ways and as the last thing in this chapter, a
classification of the protocols will be given based on how these solve the problem.

2.2.1 CSMA / CA

In Carrier Sense Multiple Access (CSMA) terminals sense the medium before
transmitting and then take appropriate action according to how the medium was found.
There are three variations of CSMA that behave in the following way:

      1-persistent CSMA: transmit immediately when medium becomes idle. (Causes
       more collisions because two terminals might be trying at the same time)
      Non-persistent CSMA: if medium is busy wait a random delay and sense the
       medium again, transmit when found idle.
      P-persistent CSMA: Transmit with the probability P when medium found idle
       otherwise delay on time slot and repeat the process (can waist time if P is small
       and if P is large more collisions will occur).

The hidden terminal problem plagues CSMA, so Collision Avoidance (CA) is needed.
CA can be added to CSMA by letting terminals transmit only after the initiator has gotten
permission from the receiver. Requests for permission are sent by addressing the receiver
with a “Ready To Send” control packet. If permission is granted by the receiver, it will
transmit a “Clear To Send” (CTS) back to the initiator. If CTS is not received by the
initiator within a certain interval it will timeout and try again. When a collision is
detected, the BEB (explained above) method is invoked. Any other terminal overhearing
either the RTS or CTS will avoid collisions by deferring from transmission during a
specified interval.

2.2.2 MACA

MACA [Karn90] stands for Multiple Access Collision Avoidance and allows for many
terminals to share a medium for data communication with help of appropriate control
messages. Interestingly, MACA abolishes the carrier sensing as this cannot be relied on
in all situations (like exposed terminal). MACA is designed to solve the hidden/exposed
terminal problems by regulating the transmitter power, among other things. A terminal
running MACA requests the medium by sending a RTS to the receiver. Since the radio
signal propagates omnidirectionally, every terminal within the sender’s radio range will
hear this and will know not to transmit. If the receiver is able to receive data at the
moment, it will answer with a CTS. This, in turn, inhibits the receiver’s neighbors from
transmitting during a specified time. The inhibition delay time for the sender’s neighbors
is equal to the longest possible time for the sender to receive a CTS plus a random delay.
The neighbors of the receiver should “keep quiet” for a time specified in the CTS (the
length of the data that the sender specified in its RTS is copied to the CTS) plus a random
delay to avoid collisions. MACA solves the problem of exposed terminal since a terminal
A receiving only a RTS addressed to a certain terminal B, can deduce that it will not
disturb the transmission to B since it has not received a CTS from B (A is not a neighbor
of B). Although MACA is data packet collision free, RTS packet collisions can still

happen in MACA and are detected through lack of CTS answer. If this happens, a BEB
delay is waited.

MACA also has a power-regulating feature, which works as follows: Communicating
neighbors include readings of the currently received signal strength in messages. This
will help the other party to lower the output signal it is using. When a suitable level,
which is strong enough to reach from terminal B to terminal A is known, B can use a
power level below this value in order to be able to keep on communicating with other
terminals although a CTS is heard. This improves overall throughput of the network.

If the size of a data packet to be sent is not much greater than the control packets then
these can be omitted. That is, a terminal can send the data immediately without the RTS-
CTS procedure. A very important point is made in [Karn90] is that the data message must
not be of critical nature since the risk of data packet collision then exist. A suitable
application of this would be the cumulative acknowledgements of TCP since it does not
matter if one is lost as long as the next one is received before the sliding window is filled

2.2.3 MACAW

MACAW (MACA with Acknowledgement) [Bharghavan+94] is a modification of
MACA. MACAW addresses a problem found in MACA in which some terminals that
have experienced more collisions will be less likely to allocate the channel before
terminals that have experienced fewer collisions. This ratchet effect occurs because every
time a terminal experiences a collision, its backoff value is doubled (and reduced to
minimal after successful exchange of RTS-CTS) and is thus increasingly likely to be
dealt longer random values to wait before accessing the channel after collision. In order
for the ratchet effect to take place the channel has to be heavily utilized and the backoff
value of one terminal is significantly higher than the competing terminal’s. This problem
is corrected in MACAW by inserting the backoff value in packets and letting other
terminals copy the value from the packet to its actual value and therefore spreading the
backoff values, keeping them on a similar level at every terminal.

An important point made in [Bharghavan+94] is that MACA relies on the transport layer
to provide the final recovery of transmission errors. As errors in TCP are often detected
after a timeout period this will inflict substantial delays. Because MACAW uses hop-by-
hop acknowledgements (ACK), the timeout values can be made significantly smaller than
TCP timeouts, thus providing faster error detection. The receiver returns the ACK to the
sender as soon as a successful transmission of a data packet has occurred. If the ACK is
not received, the data will be retransmitted. If retransmission is also unsuccessful, an
error message is sent to the initiator.

Although MACA has the useful feature of informing the sender’s neighbors of the
duration of the transmission in the RTS, the neighbors still do not know if the receiver
received the RTS successfully or if the sender is actually transmitting. A Data-Sending

(DS) packet is therefore added which is transmitted by the sender, when it receives a
CTS, with the intent that every neighbor of it is informed that a data transmission is
underway. Thus, every neighbor defers transmission during the delay indicated by the

Another problem that MACAW solves can occur when terminals are aligned in the way
shown in figure 2-4: The scenario begins when one terminal wins the initial access to the
medium, in this case D (C responds to D’s RTS) and after that relatively large data
packets (compared to the control packets) are sent form D to C. The problem arises when
A wants to transmit to B, but does not get any responsive CTS because B is deferring due
to the fact that is has heard an CTS from C. Over time, it will be very unlikely that A will
get access to the medium since its RTS should be received exactly when one data
transmission between D and C has just ended.

                             A            B             C            D

                      Fig. 2-4: B cannot respond to A because B is deferring.

The lack of synchronization between A and D (A is actually contending with D), and the
fact that the data packets are larger in size, makes it unlikely that A’s RTS will arrive at B
during a short contention period. This is why yet another packet is added to MACAW,
called “Request for Request To Send” (RRTS). This packet can be sent by B to A after it
has received a RTS from A to which it cannot send an CTS, thus letting B contend for
access in place of A since B has heard the CTS from C and will know when to request a
RTS. So, the RRTS is sent to the sender of the initial RTS (A) at the next won contention
period, which enables A to retransmit a RTS if it still has data to send. Other terminals
hearing the RRTS defer for a delay long enough to let a RTS-CTS sequence to take place
between A and B.

Simulation results in [Bharghavan+94] show that, in networks with high error rates the
benefit from the ACK messages substantially. The DS and RRTS make the allocation of
the channel fair. The message exchanges in the MACAW protocol amounts to a five-way
handshake scheme, which will have more control overhead than other protocols.

2.2.4 MACA-BI

The basic model of channel allocation was rethought in the protocol called MACA-By
Invitation [Talucci+97]. As the name suggests, it is the receiver that “invites” the sender

to send. MACA-BI uses a two-way handshake and utilizes a Ready To Receive (RTR)
message, which is the message that has to be received by a terminal before it can transmit
data. Neighbors overhearing the RTR are inhibited from transmitting during the length of
the transmission. This can be seen as a form of neighbor polling protocol. To increase the
chance that a neighbor being polled actually has data to send, the queue length and packet
arrival rate at the neighbor can be included in packet exchanges so that the receiver can
poll the terminal in greatest need of channel access. When terminals are mobile, the
MACA-BI receiver initiated method is inadequate and RTS messages can be used if a
terminal’s queue length or packet delay exceeds a threshold value. The two-way
handshake of MACA-BI drastically reduces the amount of control messages that has to
be sent in order to allocate the channel compared to other protocols. The achieved
advantage over MACA evaporates when connectionless, bursty transmissions occur
because a receiver does not know which node to poll and the RTS message has to be used
by the sender. The hidden terminal problem still exist for control messages, but as with
other MACA based protocols, two data packets can never collide in MACA-BI. The
chance of control packet collision will be half of that of MACA since half as many
control packets are used. And finally, as mentioned in [Talucci+97] collision avoidance
does not suffer from the reduced handshake procedure.

2.2.5 PAMAS

Power Aware Multi-Access with Signaling for Ad Hoc Networks (PAMAS) [Singh+98]
is also based on MACA. What makes this protocol special is that is has a separate
signaling channel with which RTS-CTS dialogue is maintained and a normal data
channel for data messages. When a terminal wants to transmit, a RTS is sent over the
signaling channel. If, however, another terminal is receiving data at the moment, it will
respond with the busy tone, which will collide with any subsequent control messages,
making it impossible for other terminals to engage in dialogue. But, if the control channel
was idle, and no other terminal is receiving data (no busy tone is put on the control
channel), the RTS will get through to the receiver and the sender then starts waiting for a
CTS (if a CTS is never received, the sender enters a binary exponential backoff state). If
the sender receives a RTS while waiting for a CTS, it will itself transmit a CTS packet
and start waiting for data to arrive. This can take place only after the receiver has replied
with the CTS, which can be done if there is no busy tone on the control channel nor is
any neighbor transmitting data (data channel is idle). When data begins to arrive at the
receiver, it asserts a “busy tone” on the signaling channel.

In PAMAS, if a terminal has no packets to send and at least one neighbor is transmitting
and another is receiving, the other terminals can power down in order to save energy. The
difficulty is then to know when to power-up the again. Probing intermittently could solve
this. In simulations power savings between 10-70% are registered (with various network
layer routing protocols). In [Singh+98] it is pointed out that overhearing packets consume
power as well (approx. 2-15 watt while receiving).

2.2.6 DBTMA

In [Deng+98] it is shown that in protocols based solely on RTS-CTS sequences (no
separate signaling channel), the probability of collisions is about 60%. To reduce this
percentage, an ad hoc version of the last hop medium access protocol Busy Tone Access
(BTMA) was developed, and was named Dual Busy Tone Multiple Access (DBTMA).
Like PAMAS, DBTMA has one data- and one control channel (for RTS-CTS) and two
busy tones for alerting others of ongoing transmission. One tone is used to signify
receive-busy (BTr) and the other transmit-busy (BTt). As usual when a terminal wants to
transmit it sends a RTS over the control channel if no BTr signal is sensed (no neighbor is
receiving). The terminal to which the RTS is addressed answers with a CTS if no BTt (no
neighbor is transmitting) signal is sensed and places a BTr tone on the signalling channel.
When the CTS reach the originator of the RTS, it can begin transmitting data, but also
sets the BTt tone on the signaling channel. Neighbors that can hear either busy tone are
prohibited from transmitting.

2.2.7 MARCH

MARCH (Media Access with Reduced Handshake) described in [Toh02] is a medium
access protocol that takes advantage of the fact that neighbors can overhear each other, in
order to reduce the amount of messages needed for a successful handshake. MARCH is
also a receiver-initiated protocol, in which the polling is done in an intelligent way. The
polling can be made intelligent by allowing MARCH to access the routing table of the
network layer. When a neighbor overhears a CTS, it will know that data is about to be
sent to the sender of the CTS. Since the neighbor has access to the network layer routing
table it can check if it belongs to the route that the overheard packet is traversing. The
overheard CTS must, therefore contain the MAC address of the CTS-sender and a route
ID (RTID), which identifies the route that the packet is traversing. The neighbor then sets
a timer long enough to let the sender of the CTS receive the data and waits for the time to
elapse. When that happens, the neighbor will know exactly which node to request data
from, that is, if the terminal that sent the CTS is on the same route as the neighbor. The
neighbor requests the data with a subsequent CTS2 message. This kind of “CTS only”
communication can be done at every hop (an RTS has to be used by the source initially)
along the route from a source to a destination, thus providing a very efficient receiver
initiated medium access protocol. Figure 2-5 displays a simple scenario using MARCH.
This MAC protocol requires that the network protocol caches complete routes like DSR
does see (section 3.5).

                                 1.RTS                4.CTS2

                           A                  B                  C
                                3. DATA

                          Fig. 2-5: C requests data from B with a CTS2.

2.2.8 HAMA

Hybrid Activation Multiple Access (HAMA) [Bao+02] is a medium access protocol for
ad hoc networks that uses techniques previously mainly found in one-hop base station
networks (i.e. mobile phone networks) called Code Division Multiple Access (CDMA)
and Time Division Multiple Access (TDMA). CDMA is basically direct sequence spread
spectrum (explained in the first section of this chapter) in which each terminal is given its
own spreading code to avoid interference. Protocols using this kind of medium access
methods are called “conflict-free” because every node can transmit without worrying
about collisions (the opposite of conflict-free is contention based, i.e. protocols derived
from CSMA/CD).

In HAMA the neighborhood is expanded to contain not only one-hop (direct) neighbors,
but also two-hop (indirect) neighbors. A terminal needs to have information about the
whole of its neighborhood. We will soon see how this information is gathered, but let us
now concentrate on what kind of information is needed and its purpose. The knowledge
of the neighborhood is used to derive topology dependant transmission schedules as a
basis for a priority scheme.

To enable conflict free data communication, HAMA utilizes a pool of carefully chosen
orthogonal (non-overlapping) spreading codes (DSSS), which are assigned to terminals.
This protocol relies on the fact that CDMA codes and TDMA time slots only have to be
unique in the neighborhood, in other words the protocol has to see to it that no two nodes
use the same code at the same time as another within two hops. HAMA supports both
unicast and broadcast transmission in a time slot with the senders spreading code, during
which no other neighbor (one- nor two-hop) can transmit. Multiple unicast transmissions
during one timeslot can take place (because of different spreading codes). One time slot is
long enough to accommodate the transmission of one packet. The priority scheme we
talked about earlier works in the following way: Each terminal will be in a state
corresponding to its own priority compared to the terminals around it. Only terminals
with a higher priority are allowed to transmit to terminals with lower priority. The
following states are defined in HAMA:

      R: receiver, is a terminal with moderate priority among one-hop neighbors
      D: drain, is terminal with the lowest priority among one-hop neighbors (the drain
       can only receive)
      BT: broadcast transmitter is a terminal with the highest priority among its two-
       hop neighbors (BT can broadcast to any one-hop neighbor)
      UT: unicast transmitter, is a terminal with the highest priority among its one-hop
       neighbors, but not among its two-hop neighbors (UT can transmit to a selected
       subset of one-hop neighbors)
      DT: drain transmitter, is the a neighbor of D with the highest priority

When a terminal compares the priorities of the neighborhood with its own and determines
that is can transmit (i.e. states BT, UT or DT) it must select a set of one-hop neighbors
that can receive its packets. On the other hand if a terminal determines that it is a receiver
(R or D states), it has to choose a one-hop neighbor with the highest priority whose
spreading code it must listen to.

There is still the open issue of how the priority information is spread in the neighborhood.
This information cannot be spread with the collision-free channel because we need that
information in order for the channel to work in the first place. For this purpose, another
channel for distributing information among one- and two-hop neighbors is used. It is a
common channel based on a best-effort model, with a known spreading code. Over this
channel the so-called neighbor protocol is run. For instance when two terminals become
neighbors they exchange complete one-hop neighbor information and both inform their
one-hop neighbors about the new link. Also, hello messages are sent over this channel in
order to maintain connectivity. In case of link breakage a neighbor delete message is sent
out. In order to avoid the control messages of the neighbor protocol to become
synchronized and cause collisions, a random amount of time is waited before transmitting
them. Lastly, we give an example (fig. 2-6) of operation in an ad hoc network based on
HAMA, also found in [Bao+02]. Here A becomes the BT because it has the highest
priority. The terminals F, G and H are Drain receivers due to the fact that they have the
lowest priorities. Nodes B and D are receivers because of their high priority neighbors.

        6               5                                                          1
        A               B                                                          F
                                      4               3           2
                                      C               D           E
                        2                                                          1
                        G                                                          H

                     Fig. 2-6: Nodes in a HAMA network with assigned priorities.

2.2.9 IEEE 802.11b

A set of techniques for wireless networking (without routing) is given in a standard called
802.11b [IEEE99], by the Institute of Electrical and Electronics Engineering (IEEE).
802.11b networks uses the ISM band with either frequency hopping7 spread spectrum
(SS) or direct sequence SS at the physical layer. For ad hoc networks distributed medium
access algorithms make sense. The 802.11b also supports centralized access with help of
a base station, but will not be discussed further here. For distributed medium access
802.11b defines an algorithm called Distributed Foundation Wireless MAC (DFWMAC).

 FHSS in IEEE 802.11b hops between 79 frequency channels; each is 1 MHz wide every 400msec (or less)
and transfers data at max. 11Mbps.

This MAC algorithm features a Distributed Coordination Function (DCF), which is also
the foundation for the optional centralized medium access method, called Point
Coordination Function (PCF). DCF uses a Carrier Sense Multiple Access with Collision
Avoidance (CSMA/CA) protocol.

When a terminal is getting ready to transmit, it will first sense the medium to ensure that
no other terminal is transmitting at the moment. If this is true, it will wait for a period
corresponding to the priority of the packet and then if the medium is still idle, transmit. If
the medium was found busy at either sensing points, it will start monitoring the current
transmission, waiting for an acknowledgement (ACK) for the transmitted data to be
overheard. During this time the terminal defers from transmitting. This also happens
when a terminal overhears a RTS or CTS and asserts a “network allocated signal” for
itself until an ACK is overheard. When the medium is sensed idle for the second time or
an ACK is overheard, the terminals aspiring to transmit will still wait for a period
determined by the binary exponential backoff method. This is done to reduce the risk of
multiple terminals sending at the same time when the medium becomes idle.

The priority scheme defines three different periods of delay, called Inter Frame Space
(IFS, this is not a frame in the normal sense, but an interval). The shortest delay is called
Short IFS (SIFS) and it is after this period time critical control packets are allowed to be
sent. This includes RTS-CTS-ACK transmission. The following delay is called PCF IFS
(PIFS), and is a medium length period only waited by a base station when it is used. DCF
IFS (DIFS) is the longest period waited and is used for asynchronous traffic by any
terminal when no traffic of higher priority exists.

So, in effect the priority scheme lets ongoing RTS-CTS conversation pass before other
traffic. After this the base station is allowed to take control in order to issue polls. The
polls are themselves of SIFS priority. When no traffic mentioned above is present,
ordinary terminals are allowed to seize the medium for asynchronous traffic. This means
that if an ad hoc network is operating while a base station is present in some
neighborhood of the ad hoc network, nodes within the range of the base station will gain
access to the medium more frequently than those communicating directly. To prevent ad
hoc terminals from starvation, a super frame (see fig.2-7) is defined. This frame contains
two parts one for synchronous, contention free traffic and an asynchronous access method
for contention based traffic. During the first part the base station may seize the medium
and issue polls to stations. After that, the ad hoc terminals may contend for medium
access during the latter part of the super frame. At the end of the super frame the base
station starts to contend for access with PIFS priority. If this takes so long that the super
frame interval is overrun, the contention free period will be shortened in the following
super frame.


     1.the BS gains                                                          2.the BS gains
     access with PIFS                                                        access as in 1.

     Polling (if BS)         SIFS, PIFS, DIFS       Trans.            Polling

          Sync. access             Async. access

          Super frame 1.                                          Super frame 2.

                                           Fig. 2-7: A super frame.

To achieve higher transmission reliability, frames can be fragmented and sent one by one.
This works because smaller frames are more likely to be received without errors. Every
fragment has its own sequence number, checksum and every fragment has to be
acknowledged before the next is sent. Larger fragment bursts can also be sent when
medium access is acquired.

2.2.10 Bluetooth

Bluetooth8 does not follow the OSI layered model, but the layer that comes closest to the
MAC sub layer [Tanenbaum03] is the Bluetooth layer called the “baseband”. Bluetooth
uses a centralized TDM (Time Division Multiplexing) protocol for channel access, which
means that terminals are synchronized in time with a central authority called a “master”
in order to know when time boundaries for transmission are. The slots are 625sec long
and half is allocated to the master and the other half to slaves. Frames can be of length 1,
3 or 5 slots (625b, 1875b and 3125b). It is more efficient to transmit longer frames not
only because less hopping is done, but also only one header is needed instead of many. A
negative effect of long frames is that the likelihood if transmission error in a packet will
increase. No direct communication between slaves is possible therefore data has to be
relayed by the master.

We will now describe how two devices find each other with Bluetooth. Before data can
be transferred with Bluetooth, identification9 and negotiation of roles (i.e. master and
slave) must take place. This is done by sending inquiry packets on a common hopping
sequence to surrounding devices if there is any. In order to have time to transmit queries
and listen for answers, the inquirer has to hop twice as fast as terminals in the listening
mode, which will reply. If there is more than one listener, the replies could collide and
they therefore wait a random period in order to avoid collisions. A device in the vicinity
replies with a Frequency Hop Synchronization (FHS) packet, which contains the

  Bluetooth (as do 802.11) operates in the 2.4 GHz ISM band of 83.5 MHz in which 79 RF channels spaced
1 MHz apart are available for frequency hopping spread spectrum.
    Bluetooth devices are identified with a 48bit MAC address.

listener’s address, class and clock offset. The device class identifies the type of device in
question and can be used to query only certain classes of devices. The sender of the query
is now able to transmit a unicast page message using the listener’s clock. If the receiver
of the page message accepts the incoming connection (i.e. it has been specified to work
with the other type of device), it will send an acknowledgement (ACK) to the pager.
Upon receiving the ACK, the pager will become the master and the paged terminal slave.
At this time the slave switches to a hopping sequence dictated by the master and the
devices can begin transmitting data. Data is transmitted in slots where one hop frequency
is used for every slot, in other words the hopping is only done between full packets. The
slots can be reserved by the slaves and are granted by the master by polling, but no
specific polling scheme is specified and this can be implemented as manufacturer sees fit.

When new terminals are to be accepted into the piconet, the master can invite them after
being discovered at page time. During the invitation-join sequence, operation in the
piconet must be suspended. Additionally, to the seven active slaves on star-shaped
piconet, it can contain inactive, parked devices in low-power mode, waking up
periodically. If a slave joins the piconets of two masters, it can combine the two piconets
into a so-called “scatternet”.

2.3 Discussion

There are basically two types of MAC protocols: The first one solves shared medium
access by letting terminals compete asynchronously and if we look globally at the
network, it is a random terminal that is allowed to transmit when two or more nodes are
competing. The second type of MAC protocol is such that it divides the medium so that it
does not have to be competed for. This can be done by dividing transmission time (slots),
a frequency band or codes between terminals and requiring them to synchronize in order
to ensure that they never use the same slot, frequency or code. In ad hoc networks only
terminals in neighborhood have to be synchronized, this is because terminals outside the
neighborhood cannot interfere with each other. In [Bao+02] Garcia-Luna-Aceves and
Bao name the first type “contention based” and the second “conflict free” protocols.

The RTS-CTS based schemes are contention based and xDMA conflict free. As the
amount of traffic increases in contention based protocols the amount of collisions will
also increase. PAMAS and DBTMA take this into account by providing a different
channel for control messages to avoid terminals interference, thus improving throughput.
It is also important to differentiate between sender initiated and receiver initiated
contention based protocols. To the group of receiver-initiated protocols belongs MACA-
BI and MARCH, in which terminals “invite” senders to transmit at suitable time. Both of
these try to make informed guesses about who has data to send, based on either meta data
included in previous packets or on higher level routing information.

Asynchronous, contention based protocol types have the following unwanted property:
As network traffic increases, the amount of collisions will also increase, which in turn
means that throughput degrades dramatically when more and more terminals are backing

off and trying again. When terminals that have backed off try again, their transmission
might collide with new traffic, adding to the number of terminals that are backed off and
are waiting for access. This is the main problem that conflict free protocols tries to solve.
There is a positive side to contention-based protocols and that is simplicity, they are
relatively easy to implement.

We can also say that conflict-free protocols are deterministic because we know for certain
that a terminal will be allowed access at a certain point in time. Contention based
protocols are, on the other hand, indeterministic due to the randomizing methods - we
cannot always know which terminal will transmit first. We have not discussed many
conflict free protocols because they have not been implemented for ad hoc networks and
research is still on going. The conflict-free protocols can be both centralized and
distributed. For instance, a Bluetooth piconet uses a conflict free centralized MAC
protocol in which time slots are divided among terminals by the master. Also, cell based,
single hop, mobile phone networks belong to this group. Interestingly, protocols which
employ clusters that contain controlling masters are also said to be centralized [Lin+95].
Therefore, Bluetooth Scatternet would also qualify as a conflict free centralized MAC

Distributed collision free protocols do not have a centralized master but terminals
belonging to a neighborhood must agree on which xDMA resources to use, so that no
terminal use the same. Therefore, the terminals are not globally synchronized, but inside
a neighborhood they must be. Assigning xDMA properties to nodes in a network based
on a collision free protocol is the equivalent of a well studied problem in graph theory
called “the edge coloring problem” in which no two edges (links) may have the same
color if they share a common vertex. Therefore, the analogue problem is that two
neighbors adjacent of a common node must not use the same spreading code. A protocol
called WAMIS (Wireless Adaptive Mobile Information System) is presented in [Lin+95].
It is also based on clusters (fully connected, i.e. every terminal has a link to every other
terminal), but without cluster leadership (thus distributed). This protocol assigns a
common spreading code to every cluster and if a terminal belongs to two clusters it is
assigned two codes. Therefore, the second thing that must be ensured is that no two
terminals ever transmit at the same time in a cluster. Intercluster conflicts will never arise
since these use different codes. Inside a cluster a round-robin medium access scheme is
enforced in order to provide transmission time fairly. A carrier sense method (CSMA-
Round Robin) can be effectively used since no hidden terminal problems can exist inside
a fully connected cluster (all terminals one hop away). WAMIS uses a clever
prioritization scheme to enable time critical traffic to be scheduled first (i.e. voice calls).
The first packet of a call uses CSMA-RR, but this packet can have a reservation control
packet piggybacked, telling other terminals that it will be this terminals turn to transmit
after a maximum time that can be tolerated with voice traffic. When link utilization is
high, this protocol will resemble TDMA but without the overhead of being time
synchronizing. Additionally, we mention that this protocol belongs to the group of
conflict free, distributed protocols. Someone might argue that this is not a synchronized
protocol, but this element can be found in the fact that clusters have to be synchronized in
such a way that these never use the same code.

Code assignment is a difficult issue in for mobile ad hoc networks and it can be done in
the following ways [Hu93]:

      Common Code Assignment (CCA), every terminal uses the same code.
      Receiver based Code Assignment (RCA), every terminal is assigned a code for
       reception such that no two neighbors of a terminal has the same code. In RCA a
       terminal only has to listen to one code (Every transmitting node uses a particular
       code for a particular receiving node). Every terminal is assigned a code for
      Transmitter based Code Assignment (TCA), all neighbors of a given terminal,
       have a different code for transmission so that no two neighbors of the node ever
       transmit with the same code (Every transmitting terminal uses one code for
       transmission and every receiving terminal listens to different codes). Every
       terminal is assigned a code for transmission.
      Pairwise Code Assignment (PCA), here codes are assigned to transmitter receiver
       pairs, such that no to adjacent links have the same code. A PCA code is used for
       both reception and transmission.


          Contention based                Hybrid                       Conflict free
          (Distributed,                                                (Synchronized)

 Receiver                 Sender                           Centralized                  Distributed
 Initiated                Initiated

                          Fig. 2-8: Classification of MAC protocols.

To the group of hybrid MAC protocols we place HAMA. HAMA utilizes a contention-
based scheme in the neighbor protocol and a conflict free protocol for data transmission,
thus this is a hybrid protocol. A taxonomy graphic of MAC protocols is shown in figure


Designing an optimized routing protocol for an ad hoc network is one of the most
challenging tasks in computer science. When designing a centralized program, one only
has to take into account the inner timings of the program, while in a distributed system
the different copies of the program interact through more or less reliable links. These
links introduce delays or losses in the communication flow, which adds to the non-
determinism, and unforeseen situations can emerge. Network protocols use timers to
deduce things about the state of the communication flow. For instance, a protocol can
have a timer that "guesses" when a message is lost. This temporal problem is difficult to
assess, as too long or short timeout periods will result in unwanted behavior. When we
then add the possibility of mobility to this equation, we will have to deal with yet another
uncertainty, the spatial factor. One can never be sure that a computer that was just within
the radio range is there a second later. So, when an unguided transmission medium is
used, the protocol designer’s job will be even more difficult. In packet switched networks
for instance, a failure or disappearance of a node can put a great deal of strain on another
node that has to be equipped with hardware and logic to deal with this situation. In this
chapter we will categorize ad hoc routing protocols and talk in depth about a few
protocols currently being considered as standards by the IETF10.

3.1 The Routing Problem

Ad hoc routing protocols perform the same task as routing protocols in fixed networks. In
fixed Internet for instance, a host can only communicate with directly connected hosts, on
the same subnet. The same applies to ad hoc nodes - they can only communicate with
directly connected neighbors, that is, if a routing protocol is not provided. An analogy can
be made between Internet, which connects distant networks, and ad hoc network
protocols, which connects distant hosts. The routing protocol is a piece of software that
utilizes the links to neighbors, provided by the data link11 layer to disseminate
information about the current topology of the network. When nodes know the topology of
the network, they can instruct an intermediate node to deliver its packet to a node that is
not a neighbor of the source of the packet. Routing protocols generally solve the problem
of discovering the topology by letting nodes gather information about its neighbors (i.e.
link metric cost and neighbor ID) and then sending this information to the neighbors and
they in turn pass it on. For fixed networks there are mainly two classes of routing
protocols: links state and distance vector. Link state type protocols solve the routing
problem by requiring that every node gathers information about the links to their
neighbors, consisting of the cost to traverse the link and the ID of the neighbor. This
information is then relayed in a Links State Packet (LSP) throughout the network so that
every node receives information about every node’s links to their neighbors. Based on

     Internet Engineering Task Force
     Data link layer consists of the logical link control layer and the MAC layer.

this information, a shortest path algorithm can be run, which calculates the shortest path
to every destination node and will thus be aware of the next node towards that
destination, also called the nexthop.

Nodes running distance vector protocols also initially send information about their
neighbors initially. The difference here is that the whole routing table is sent to the
neighbors (initially containing only neighbors). When a node receives the routing table of
another node it first checks whether there is any, to the receiving node unknown
destinations mentioned in the received routing table and copies theses to its own.
Secondly, it compares the distances for destinations in its own table, to those in the
received table. If a shorter route is found via another neighbor (nexthop), the routing table
entry concerning the destination is updated to the shorter route. Route entries essentially
contain a nexthop (direction of the vector) and a distance for every destination. After
routing information has converged (updating is done infrequently), every node on the
shortest routes, can forward a data packet in the right direction when requested to do so.
When a node updates its routing table, it also sends the updated version (contains
multiple hop routes at this time) to its neighbors. It is a well known fact that message
loops can occur in distance vector protocols, but despite engineered remedies12 these
cannot be eradicated completely.

3.2 Proactive and Reactive Protocols

The protocols in the above section are designed for fixed networks where changes in the
topology rarely happen. This allows for so-called “proactive” (also called table-driven)
protocols where a change in the topology is propagated globally to inform every node in
the network instantly. In ad hoc networks may not be an optimal strategy because routes
might be maintained unnecessarily. The nodes in an ad hoc network are mobile and if
these move at a high speed, the whole network would constantly forward control packets
in order to have an up-to-date picture of the topology, reducing available bandwidth 13
that could be used for data packets. The advantage of having up-to-date information at all
time might not be necessary since it is unlikely that every node needs to communicate
with every other node. Therefore, routing protocols for ad hoc network have been
developed that discover routes on an on-demand basis. These protocols are called
“reactive”. Although possible, in ad hoc protocols it is more important to differentiate
between reactive and proactive, rather than link state and distance vector type protocols.
Finally, it can be said that ad hoc routing protocols have to minimize message complexity
(amount of relayed messages) at the expense of having up-to-date routing data, extending
delays. In the following sections we shall see how different protocols try to optimize this

     Poisoned-reverse & split horizon
     The word bandwidth is used here to denote the data transfer rate.

3.3 Classification of Ad Hoc Routing Protocols

In addition to proactive and reactive routing protocols there are several other more or less
special types of protocols, some of which will not be considered further after this chapter.
These include hierarchical, geographical and power aware type protocols as classified in

Hierarchical routing protocols divide the topology into zones or clusters, often with a
cluster leader and different intra- and intercluster protocols. As an example of a
hierarchical protocol we mention Zone Routing Protocol (ZRP), which partitions the
network into zones and permits proactive routing inside a zone. When a route is needed
to an outside node, a reactive route request message is broadcast. This limits the length
that proactive updates travel (compare: autonomous systems and the backbone in the
Internet). ZRP can also be called a hybrid protocol since it has both proactive and
reactive features. When inter-zone route requests are sent, zones that have already been
searched can stop the request message from entering it again, further reducing message

Geographical protocols utilize location information that has to be acquired with Global
Positioning Systems. In order for these protocols to become more common, GPS will still
have to become more affordable. For example, a geographical protocol named, Distance
Routing Effect Algorithm for Mobility (DREAM), maintains a complete list of node’s
positions so that data packets can be flooded in the right direction. Location Aided
Routing (LAR) is a reactive geographical protocol. This protocol also uses the
information provided by GPS to send a limited route request to a so-called expected zone
(Fig.3-1), which is formed as a circle area of where the destination is expected to be,
based on the latest information about the location, direction and speed of the destination.
There is also a limited request zone defined in LAR. The request reaches an area formed
as a rectangle by a diagonal from the source to the expected zone. When the destination is
to be found, a route discovery message is flooded only in the request zone and in the
direction of the expected zone.

                          Request Zone                            Expected Zone

                                   Fig. 3-1: The zones of LAR.

In power aware routing the protocol does not prioritize short routes anymore, but rather
tries to select such routes that will optimize battery consumption in the network. If a route
contains nodes with low battery levels, a longer route is chosen if available. In this
attempt it is also important to minimize the amount of power that the transmission of a

packet consumes. From a battery consumption point of view, it is not wanted that one
node is responsible for forwarding packet between many source-destination pairs.
Therefore, some sort of load balancing should be implemented. The Minimum Total
Transmission Power Routing (MTPR) protocol for instance, prefers routes with more,
shorter hops rather than those with fewer hops and longer transmission ranges. This is
done because less power is required for shorter distances. Therefore, routes requiring
least power are chosen. MTPR does not, however, take into account the remaining power
levels of individual nodes, which is done in a protocol called Min-Max Battery Cost
Routing (MMBCR).

MMBCR considers the remaining battery level of every node and lets those with lower
levels participate in forwarding more seldom. This is performed by MMBCR in the
following way: Every route between a source and a destination has a node with the lowest
battery power level (weakest node). Every weakest node is then compared and the route
with the strongest weakest node is chosen. But as mentioned in [Kim+02], MMBCR does
not guarantee that the total transmission power is minimal. MMBCR does, however,
prolong the battery lifetime of the whole network.

Conditional MMBCR (CMMBCR) considers both the total transmission power used by
each route and the remaining power of nodes. CMMBCR first considers only routes
where every node has a power level above a threshold and when the power level of every
route between the source and destination is below the threshold, a route is chosen like
MMBCR. This means that MMBCR first chooses routes that consume the least power
from a set that still has a certain level of power left and then when these no longer exist,
the route that contains the highest power capacity node of all minimum power level nodes
is chosen (A summary of MTPR, MMBCR and CMMBCR can be found in [Kim+02].

3.4 Ad hoc On-Demand Distance Vector (AODV)

AODV [Perkins+99] is a reactive protocol that has evolved from Destination-Sequenced
Distance-Vector Protocol (DSDV). DSDV is a proactive protocol (based on the Bellman-
Ford algorithm) in which every node maintains routes to every other node all the time.
The routing metric is hop counts and sequence numbers are used to discriminate older
routes. AODV requires network wide broadcasts only when a route is acquired and the
node has no previous knowledge of the topology. AODV also supports multicast and
broadcast communication, which is extremely important when large pieces of data is to
be transferred from one node to many nodes (i.e. multimedia such as motion pictures).
AODV utilizes two routing tables, one for unicast routes and another for multicast routes.
A route entry consists of destination, next-hop and distance (in hops, equals the amount
of links between the source and destination). The route entries also have an age and a
sequence number associated generated by the destination in order to prevent loops (no
node is misinformed of old routes). The age is used to remove entries that have not been
used for a while and therefore are likely to be ruined because of node movement. Each
time an entry is used, the age is set to zero. When routes are used and found to be broken,
these are maintained using a process described in section 3.1.2.

3.4.1 Route Discovery

When describing the route discovery process the node that initiates the process will be
called the source and the node that the source tries to contact is the destination. When a
source wants to send a message to a destination in a network running AODV and it does
not have a route to the destination, the source has to initiate a “route discovery process”.
The process is started by broadcasting a “route request” (RREQ) to its neighbors. The
neighbors does the same, as do the neighbor’s neighbors and so on until the RREQ
reaches the destination or a node with a “fresh enough” route to the destination that can
send a “route reply” (RREP) to the source. The freshness is determined with sequence
numbers that are coupled with every route and RREQ and route entry.

The source node’s RREQ message contains the following fields:

              Source node’s IP address
              Source node’s broadcast ID
              Current sequence number of the source node
              Destination IP address
              The last known sequence number of the destination
              Hop count

The broadcast ID is incremented every time a node initiates a route discovery process and
a timer is started when a RREQ is sent. Every intermediate node that receives the RREQ
checks the broadcast ID and IP address combination (stored by every node) in order to
see if the message has already been forwarded. From every unseen RREQ a reverse route
entry is set up consisting of the sequence number, forwarding neighbor address (next hop
back to the source) and the source of the RREQ is stored. Also, the intermediate node
notes the number of hops to the source.

On the other hand, if the message is identified as seen, it will be dropped. If a route is not
used a specified amount of time it will be deleted from the routing table to prevent stale
routes from being disseminated.

When an intermediate node receives a RREQ and it has a fresh (the sequence number
associated with the route in the intermediate node’s routing table is at least as great as the
one found in the RREQ) route to the requested destination, the intermediate node can
unicast a RREP back to the source. The role of the intermediate node can, of course, be
handled by the destination if the message propagates that far. If the intermediate node’s
route entry is not fresh enough it has to forward the RREQ to every neighbor and
increment the message’s hop count. If the destination is not found (the source node’s
timer expires), it can try again for a number of times before notifying the application of
failure. Other than controlling the freshness property, the sequence numbers can also be
used to prevent routing loops. The RREP contains the following fields:

              Source node’s (originator of the RREQ) IP address
              Destination IP address
              Sequence number that the destination generated for this route
              Hop count
              Lifetime

As the RREP travels back to the source, every intermediate node updates pointers for the
node from which the RREP came, the timer for the source and destination, and records
the latest sequence number for the destination. If multiple RREQs are received by an
intermediate node, copies that arrive after the first one are forwarded only if the hop
count is smaller than previous copies.

3.4.2 Path Maintenance

To assert the symmetric condition of links between neighbors, hello messages can be
used in case no other packets are sent to all active downstream neighbors during a
specified interval. Hello messages have TTL value of 1 and are thus not allowed to be
forwarded. The hello packet contains the sender’s id and its unincremented current
sequence number. When a broken link is detected (i.e. failing to receive
allowed_hello_loss consecutive hello messages) a specialized RREP message is sent to
affected “active” neighbors by the node upstream of the break. The specialized RREP is
unsolicited and contains a newer sequence number than that of the broken route, the hop
count is set to . Every intermediate node’s routing table entry also contains a list of
active neighbors. The active neighbors are neighbors of the intermediate node, but these
send packets actively to the destination indicated by the entry. A neighbor is said to be
active if it originates or forwards a packet for the destination during the last
active_timeout period. When the active neighbors receive the RREP they also send a
RREP to their active neighbors for that particular broken route and so on until the start
nodes of every route are reached.

                     1        RREP 5 

                                   2                  4
                  RREP 5             RREP 5 


                         Fig. 3-2: Link breakage between node 4 and 5.

In figure 3-2, node 4 can check its routing table to see that node 2 has forwarded or
originated a packet for node 5 in the last active_timeout period which causes an

unsolicited RREP to be sent to node 2. Node 2 determines the same for node 3 and 1 and
sends RREPs. After this every node that previously used node 4 as an intermediate node
to the destination node 5, now knows that this path does not work anymore. If nodes 1, 2
or 3 still have packets to send to node 5 they must initiate a route discovery process.

Because the RREPs are unicast back to the source, AODV has to be run in a network
with symmetrical links [Toh02], in fact this condition is tested when a node is about to
forward a message. The link over which a message should be forwarded is first checked
to see if a hello message has been received over that link during the last
allowed_hello_loss period. Asymmetric links can persist when two nodes are in the
vicinity of each other, but only one of the node’s radio range reach the other node, due to
nearly depleted batteries.

In a most cases, the route discovery process will affect almost the whole AODV network
and every node receives RREQ. Actually, the process can continue although the
destination is found. To alleviate this problem, a so-called “expanding ring” search is
implemented. This works by setting the “time to live” (TTL, decremented by each
forwarder and the message is discarded when it reaches 0) value in the RREQ to
something less than the network diameter (the longest path through the network). If no
RREP is received by the source it will increase the TTL in the next RREQ. The TTL can
be guessed quite accurately if the source has been in contact with the destination before,
thus having the knowledge of the path length between them last time the route was
functioning. It is questionable, however, whether this “remedy” is effective if educated
guesses cannot be made. For instance, consider what happens when the TTL is estimated
just a little too short. In that case the route discovery process is initiated again, meaning
that message complexity for finding the destination is almost doubled. If the destination
happen to be just outside the perimeter of the first message’s reach, it would have been
more effective to let the message propagate further. In the case when there is a maximal
length path between the source and destination and the destination does not have a clue
where the destination is, there might be a multiple amount of message complexity if
many RREQs are broadcast by the source.

3.5 The Dynamic Source Routing (DSR) protocol

DSR [Johnson+96] uses its Route Discovery and Route Maintenance mechanisms to
discover and configure source routes. DSR is a reactive protocol which discovers routes
when needed. When a node forwards a discovery packet it adds itself to the route that has
accumulated in the packet header. An interesting feature of DSR is that it supports
unidirectional links if the underlying data link protocol supports this. DSR is also
integrated with mobile IP (See mobile IP in 4.1). In contrast to AODV, DSR uses
multiple routes, that is, the node that answers all the discovery messages it receives.

3.5.1 Route discovery process

The route discovery process works as follows: If the sender has a route entry for the
destination in its routing table it will copy that route to the header of the packet it is about
to send. It will then transmit it to the first intermediate node in the route entry, which will
know where to forward this package in order for it to reach its destination. If the sender
on the other hand does not have an entry for the destination it will initiate a Route
Discovery. The source node issues a Route Discovery by broadcasting such a message
that contains the sender, destination, request ID and an empty intermediate node list. The
intermediate node list is filled when the neighbors, in hope that the nexthop is the
destination, rebroadcast the Route Request. Naturally, when the Route Request reaches
the destination, it will send a Route Reply back to the source. If an intermediate node has
an entry of a route to the destination it can stop the discovery process and concatenate the
remaining hops to the accumulated route in the header so far and send this to the source
of the Route Request. This is only allowed if the node that concatenates is itself part of
the route. This limitation is required so that valid routes can be ensured. The Route Reply
can be sent in a number of ways back to the originator of the Route Request. The logical
approach would be to reverse the route found in the Route Request but this is possible
only if every nexthop link on the route is bidirectional as required by IEEE 802.11. So, if
a route to the source of the Route Request is not found in the routing table of the
destination node and at least one node’s link in newly discovered route is unidirectional,
then the destination must initiate a Route Request of its own. The second Route Request
run the risk of starting a loop since the source of the first Route Request still does not
have a route for the destination, making a Route Reply to the source of the second Route
Request impossible. Therefore, a precaution must be taken in the form of a piggybacked
message. The second Route Request from the destination node must piggyback the Route
Reply onto its own Route Request message. Data messages for which addresses are not
found in the routing table are kept in a send buffer until a Route Reply is received. A
node cannot send an arbitrary amount of Route Requests, but is confined to an
exponential backoff waiting period if a destination is not found.

3.5.2 Route Maintenance

Route Maintenance is a mechanism to ensure that the source route is intact and is defined
in the following way: Every intermediate node that forwards a data packet is responsible
for making sure that the packet was received by the nexthop neighbor. This can be done
in a number of ways. If lower level protocol support is provided then this can be done by
noting when the nexthop neighbor forwards it by listening for the next node to forward
the message - this is known as "Passive hop-by-hop acknowledgement". An active
acknowledgement can also be used at the link layer but if none of these are available, a
network level DSR message must be used. When an acknowledgement is not received
after a certain number of retries a Route Error is passed back to the source of a packet,
which removes the route to the destination from its routing table and tries another route if

it has one. If no other route is found, a new Route Discovery message has to be sent.
Route Errors can also piggybacked on Route Discovery messages in order for this
information to spread quickly throughout the network.

When a node initiates a Route Requests there is a possibility that many nodes will have a
route to the requested node, causing them all to answer the request. This will waste
bandwidth, so a counter measure is taken. Whenever a node is about to send a Route
Reply from its own cache, it will first backoff for a period corresponding to the length of
the route to the source of the Route Request. During this time the answering node has its
network interface in promiscuous14 mode, listening for a sign that the source has started
using another shorter route. If not no such packet is registered by the answering node, it
will send a Route Reply.

3.5.3 Reflecting Shorter Routes

Route shortening can be done by a node z operating in promiscuous mode when
overhearing a transmission of a packet. This feature is useful when two nodes have
moved closer to each other since they first started communicating. Suppose the scenario
depicted in figure 3-3.

                                    Packet 1
       Source                 x                      y                    z

          Fig. 3-3: A   partial route where x forwards a packet to Y also heard by node Z.

Here, x and z have moved within radio range and z can therefore overhear the packet
intended for y. From the header of the packet z can infer that it is the nexthop after y. In
this situation z can send a gratuitous Route Reply to the original source of the packet
containing a new route. This Route Reply contains the same route except that y has been

3.6 Optimized Link State Routing

The Optimized Link State Routing Protocol (OLSR) is a table driven, proactive protocol,
which exchanges topology information regularly with other nodes in the network. As the
name implies, the protocol is an optimized version of the classical link state routing
algorithm, modified for the requirements of ad hoc networks. An obvious advantage of
proactive protocols is the shortened latency when routes are needed. On the other hand, a
drawback of this is increased control traffic with unnecessary message passing, as all

     A node in promiscuous mode registers every packet it hears even if it is not addressed to the node.

routes might not be needed. The authors of OLSR have taken this into account and
reduced the amount of LSPs (see 3.1) by sending these only to a subset of its neighbors.
The LSPs are called Topology Control (TC) messages in OLSR. Neighbors included in
the TC are so-called Multipoint Relay Selectors (MPR), which are designated forwarding
nodes for TCs. The other neighbors of the node only read the TC but do not forward it. In
OLSR the age of a TC message is determined correctly on basis of sequence numbers. As
a node is on the move, it develops links to new neighbors and in order for movements to
be detected, control messages have to be sent with a high enough frequency. A necessary
condition that the MPRs of a node n have to fulfill, is that they combined have bi-
directional links to every node that is located two hops from n (some MPRs have links to
some 2-hop neighbors, but every 2-hop neighbor hears some MPR of n). This condition is
necessary for ensuring a complete broadcast (Fig.3-4 displays this configuration). When
routes are calculated, only MPRs are taken into account as intermediate routers for a
destination. Every node that receives information about another node’s MPRs will update
its tables so that routes to destinations are calculated along these MPRs.

               Fig. 3-4: A part of a converging OLSR network. The fat circles are MPRs. 15

OLSR also uses hello messages in order to establish link functionality between neighbors.
The hello message contains the neighbors of the source of the hello message. A node
concludes that its neighbor is accessed over a bi-directional link when it receives a hello
message where the node finds itself listed.

The sequence number of the TC is used for comparing incoming TCs and discarding old
ones. The list of MPRs in the TC does not have to be complete in a single message, but as
messages are sent during a specified period, all the MPRs have to appear in some of the
messages in order to build a routing table. If a change in the MPR set of a node occurs

   This picture is part of a demonstration found at the OLSR homepage

then a TC is sent before the next TC was originally scheduled. Recorded TCs are
discarded after a specified time period. The information extracted from TCs (MPR,
Destination, Cost between the two) are recorded in a database and then calculated in the
same way as in the basic Link State algorithm.

3.7 Discussion

Every protocol tries to reduce control message overhead and therefore provide better
scalability. In AODV an expanding ring search is specified in order to reduce control
message complexity. ZRP limits the propagation of control messages by partitioning the
network into zones from which certain messages cannot propagate. As we saw in OLSR,
it reduces flooding of messages by making sure that only certain nodes can forward these,
effectively reducing the message complexity.

In the discussion of proactive versus reactive protocols, the winner is determined by the
main goal one wants to achieve with the network. If we know that delay sensitive traffic
like IP telephony is going to be used then the proactive type will be the winner as these
reduce delays due to the fact that routes are always available. On the other hand if, as
much as possible of the available data rate has to be preserved for applications like file
sharing for instance then reactive protocols should be used. In fact, there is also a
proposition for so-called Active Networks (AN) [Tschudin+00], in which no single
protocol is used. Instead AN allows a programmable architecture to be tailored for certain
needs of traffic types (i.e. quality of service, topologies and mobility patterns). So
actually, many protocols may be run in parallel (distributed as control packets) allowing
the most suitable to be chosen.


Different TCP implementations for wireless ad hoc and cell based single hop networks
have been proposed. This has to be done because it has been shown that ordinary TCP
does not work well in ad hoc networks. Results of [Bakre+95] indicate a 62% drop in
throughput when stationary nodes are compared with mobile nodes, roaming between
non-overlapping cells, using ordinary TCP.

The ad hoc network is connected to static Internet by one or more fixed neighbors (base
station) over a wireless interface. The static node also connects to the Internet via a wired
interface. The ad hoc network can either be a network of the Internet or subnet of a
network. This allows the ad hoc subnets internal structure to be hidden from the rest of
the Internet, and the nodes are accessed by the rest of the Internet only through a static
redirection node (home agent in Mobile IP, see 4.1). The home agent knows to which
Internet router (foreign agent) the mobile node is currently connected. The redirection
node can be located anywhere on the Internet. This allows the ad hoc nodes to have non-
uniform addresses, (addresses with different network identifiers) in the view of the rest of
the Internet.

4.1 Mobile IP

In [Lei+97] Lei and Perkins report on their system for providing Internet access to mobile
nodes. It based on a modified version of Mobile IP in which the foreign agent’s coverage
is extended to the ad hoc network. Basic Mobile IP provides nomadic access for one-hop
wireless subnet members by having a foreign agent connected to the subnet, accepting
registrations from visiting nodes. The so-called home agent on the mobile node’s home
network is also informed when registration occurs and can therefore forward messages
intended for the mobile node via the foreign agent. This operation is known as binding
and it sets up a tunnel between the agents and the mobile node can access the rest of the
Internet through the foreign agent that will be the default router for the node.

The proposed ad hoc version of Mobile IP is used by a mobile node to locate foreign
agents on the Internet by issuing router discovery messages, which is answered with an
agent advertisement by the foreign agent. Since the foreign agent and ad hoc nodes might
not be in direct contact, the Mobile IP was paired with a special version of the Routing
Information Protocol (RIP), to relay foreign agent advertisement messages. In this
scheme RIP and Mobile IP has access to the kernels routing tables and can insert routing
entries associated with both protocols, for instance, a nexthop towards the foreign agent.

4.2 Connecting to the Internet – TCP-I

In order to provide TCP/IP successfully for ad hoc nodes, modifications to the transport
layer has to be made. A technique for handling TCP connections called Indirect TCP (I-
TCP) [Bakre+95] exists. I-TCP solves the problem of non-terminated TCP connections
caused by roaming between fixed cells. In this scheme, so-called Mobile Support Routers
(MSR) was placed in every cell. Mobile nodes connect to the MSR which in turn is
connected to the Internet, forming a TCP connection with not only two end points but
also an intermediate point. The retransmission timers are tuned to take the unreliability of
radio links into account by supporting notifications of link breakage to the MSR. The
cell’s MSR is responsible for managing all the mobile node’s TCP connections, visiting
that cell. When the mobile node moves from one cell to another, the sockets connecting
the mobile node and Internet node are migrated to a new MSR in the new cell. This is
enough to keep the TCP connection alive.

When a mobile host wants to connect to a fixed host on the Internet, it will contact the
MSR which will in turn complete the connection on behalf of the mobile node and
thereafter continue to relay the stream. The operation of moving the sockets from one
MSR to another is a complex task and is done in the following way: TCP segments that
are in transit are buffered by the sender for retransmission if they become lost during
roaming. Next, the socket state is freezed and migrated to another MSR (the old and new
MSRs communicate directly), which restarts the connection. In order to enable static
Internet nodes to find mobile ad hoc nodes, Mobile IP must be used. A logical choice
would be to make the MSR a foreign agent. It must also be noted that TCP-I does not
work in multi-hop ad hoc networks, but the principal is inspiring for future development.
In order for TCP-I to work in ad hoc networks it must be modified for multihop support
like TCP-BuS, which is discussed in the following section.

4.3 TCP within the Ad Hoc Network – TCP BuS

If a link on which a fixed TCP connection is active breaks, the flow control algorithm of
the sender will deduce that it is overrunning the intermediate routers and slows down its
operation. This will cause momentary degradation in throughput when the connection is
restored. Nodes running TCP-BuS [Kim+01] can report link breakage, with help of a
feedback utility (TCP-F [Chandran+98]), by letting an intermediate node between the
sender and its destination, report breakage in the route with Route Failure Notification
(RFN) messages. Upon receiving a RFN from the upstream node the sender enters a
snooze state, halting all transmission, freezing timers and the congestion window
(explained below). The receiver also starts a Route Failure timer, which indicates a time
limit for route repair when firing. Meanwhile, the reporting node tries to find another
route for the packets. When succeeding with the route repair it notifies the sender with a
Route Re-establishment Notification (RRN). In figure 4-1 failure point node 3 detects
link breakage and sends RFN to node 2, which forwards it to the active sender 1. Both

will invalidate the particular route. Node 1 freezes and waits for RRN. When node 3
repairs the route through node 5 and sends a RRN then sender 1 resumes transmission.

                         1                 1.RFN

                                                 3    FP



       Fig. 4-1: Detection of link breakage.   Messages are enumerated chronologically.

When resuming transmission because of an expiring timer it will be done in a way
inherited from versions Tahoe and Reno of TCP called slow start and congestion
avoidance, described in [Stevens97] and developed by van Jacobsen. In this scheme a
congestion window (cwindadvertised window, which relates to the buffering
capabilities of the receiver) is added to the algorithm which calculates the remaining
buffering resources of the network (intermediate routers). The sender assesses this by
using ACK timeout or multiple ACKs as indicators. After packet loss the congestion
window is set to one and then opening the window almost exponentially after every
acknowledgement. Figure 4-2 shows how the congestion window expands: At the
beginning cwind is 1, allowing 1 segment to be sent and acknowledged. This allows
cwind to expand to 2 and two segments are sent. When these two segments are
acknowledged cwind expands to 4 and so on.

                             cwind               Acknowledged segment
                                 1                          1
                                 2                          2,3
                                 4                          4,5,6,7
                                 8                          8,9,10,11,12,13,14,15
                                      Fig. 4-2: Cwind expansion.

The sender is therefore limited to sending no more segments than the two mentioned
windows specifies. TCP’s congestion control includes in addition to slow start, a scheme
called congestion avoidance. This means that whenever congestion occurs, the cwind is
set to half and the increase after that depends on whether TCP is performing slow start or
congestion avoidance. Another variable needs to be introduced in order to determine this
and that is ssthresh, which is initially set to 65535 bytes. If cwind is less than or equal to
sstresh, TCP is in slow start, otherwise congestion control is taking place. If slow start is
going on, it will continue until reaching cwind, which was set to half when congestion
occurred. At this time the congestion avoidance takes over, which imposes a linear
increase every time a segment is acknowledged.

TCP-BuS takes the segment partition of TCP-I (wired and last-hop wireless segment) and
extends the wireless partition to support ad hoc networking and distributed congestion
control - TCP-BuS lists the following enhancements [Toh02]:

(1) Explicit notifications, which work in the same way as RFN-RRN in TCP-F, except
here they are called Explicit Route Disconnection Notification (ERDN) and Explicit
Route Successful Notification (ERSN). The nodes that wait for route repair upstream of
the node that detected the failure point (FP), will upon receiving an ERDN, use (2)
extended timeout values for the buffered packets destined for the unavailable source. (3)
Selective retransmissions requests can be made to the source before their timeout values
expire. A scheme for (4) avoiding unnecessary requests for fast retransmission has also
been included. The destination node has the ability to request retransmission of lost
packets. This requires the destination to continue to send acknowledgements indicating
the expected packet sequence number since TCP-Reno will retransmit segments of which
duplicate ACKs are received. TCP-BuS implements (5) reliable transmission of control
messages by sensing that per-hop transmissions actually are successful. The per-hop
reliability can be achieved by letting the sender “overhear” that the receiver has
forwarded the packet to a third node. Explicit acknowledgements may also be used.
Additional reliability can be provided by letting the source send so-called PROBE query
messages to the FP to inquire if the route has already been repaired.

In [Kim+01] the reported simulations of TCP-BuS were performed by letting it run on
top of the routing protocol called Associativity Based Routing (ABR). ABR was altered
to handle the TCP control messages i.e. these are integrated into the ABR routing
messages. When beginning transmission TCP-BuS uses slow start until an ERDN is
received. When this happens, activity is frozen. The ERDN message contains the last
segment that the PN could not send due to breakage (ERDN_GEN_SEQ). Also, the last
segment sent by the source (ERDN_RCV_SEQ) before it received an ERDN. When the
route is repaired by the PN, i.e. the PN receives a REPLY from the destination - the PN
can from this extract the last segment received by the destination (LAST_ACK). The PN
copies this value to the ERSN and sends it to the source. Since the PN also sends an RN
to the source it also invalidates the route and flushes the buffered packets. The source can
then correctly assume that LAST_ACK + 1 to ERDN_GEN_SEQ -1 were discarded by
the network. As an example let us say that:


Then, the source knows that the segments 15 to 20 are buffered at the PN and will be
transmitted at reconnection to the destination. When the ERSN with the LAST_ACK
arrives at the source it can deduce that messages 11 to 14 has to be retransmitted, since
they are guaranteed to be discarded.

The results of [Kim+01] were gotten with a simulator with the following settings. The
network and transport layers were modeled assuming fixed nodes with 50m of
omnidirectional radio range, randomly failing links, and a transmission data rate of
19.2Kbps. The segment size was set to 640 bytes. Since the simulator simulates mobility
by disconnecting links randomly and not because of node movement it will not capture
all phenomena found in the real world. For instance, when two nodes move in the same
direction with the same speed and the distance is barely small enough to keep the link up,
can cause oscillations in the routing protocol, especially in proactive protocols. This is
because the link goes up and down time after time causing many control messages to be
sent. In any case, the simulator provides a fair basis for all the tested transport protocols.
First, they examine what kind of effects the route lengths have on the delivery rate of
packets (congestion ignored). In this test TCP-BuS shows, on average 15% to 30% better
delivery rate than TCP and TCP-F as the routes grow from 0 to 18 hops. The following
test was done to evaluate the delivery rate with respect to the frequency of link failure.
Here randomly chosen links are congested for a period of 10 seconds. TCP-BuS
outperforms the other two by 10% to 30% on average. It is also clear from the test that
TCP performs significantly poorer then the other two since it invokes its congestion
control procedures and stays in idle state for a shorter period after breakage occurs. In the
third test they measured the delivery rate in increasing congestion durations and found
that the selective retransmission mechanism helped in improving the delivery rate and
again TCP-BuS outperforms the other protocols. Among other tests, the segment
sequence numbers were observed at the source with anticipated outcome. TCP continued
to transmit after link breakage causing extensive retransmissions of the same segments.

4.3.1 Domain Name Service

The section above solves the Internet connection problem, but we would also like to use
textual IP addresses. As with static Internet, the users do not want to remember numeral
addresses and the same goes for ad hoc Internet. Providing textual addresses is slightly
harder in ad hoc networks, as this is the case with many things in these kinds of networks.
When a fixed Internet node is passed a textual address, it first contacts a domain name
server which has a textual-to-numeral address reference table. The DNS server passes the
numeral address back to the node which can then contact the intended node. In ad hoc
networks we cannot assume that a node will always be present in the network. This is
why we cannot rely on a DNS server to be present either.

An idea that came to our mind was to intertwine the lookup of IP addresses with the
routing functions. IP uses numeral addresses for the purposes of routing in the ad hoc
network, but textual IP address could be included in discovery messages (reactive
protocols) or in the updates (modified RIP). This would enable every node to learn the
textual name of every other node and facilitate a local DNS reference table. When the
textual addresses are added to the route requests or updates, it is clear that they will
increase in size. It is at least certain that a distributed scheme has to developed as no
single node can be relied on to always be reachable. It will remain to be seen whether
such applications are required between ad hoc nodes that textual addresses are needed. If
not, the solution is simple. The only purpose of TCP/IP is to provide access to the
Internet then a stationary DNS server will suffice since the gateway to the Internet is
stationary anyway.

4.4 Discussion

It is clear that a scheme like TCP-BuS has to be used in order to provide Internet access
to ad hoc nodes, but we are not convinced that Mobile IP is necessary. It might be
feasible implement a dynamic DNS service that would be updated every time a node
roams to another network. When Mobile IP is used we have two levels of indirection –
first the textual address has to be looked up from the DNS server and then the home agent
has to be contacted to get the current position of the mobile node. With a dynamic DNS
the address lookup would instantly yield the current position of the mobile node indicated
by the network portion of the IP address.


The Tree Routing Protocol (TRP) is a routing scheme for Ad Hoc mobile multihop
networks, which is able to discover and maintain network topology information needed
for sending information from every node to every other node on the same network. The
TRP was specifically designed for this thesis in order to provide a case study to be
examined. Like many routing protocols, TRP has a strategy to minimize the amount of
control overhead needed for discovering routes between source nodes (or originator) and
destination nodes. There is a trade-off between having up-to-date routing information and
minimizing the amount of control overhead. Reactive protocols only discover routes on a
demand basis, but when initialized the only prior knowledge about the network that a
node has is its neighbors. In a worst-case scenario, this forces the discovery process to
contact every node in the network. It is this trade-off that TRP attempts to optimize by
having partial up-to-date routing information at every node, which can be used to make
intelligent routing decisions most of the time.

5.1 Definitions

In the following text we will use traditional terms for network components, like node for
vertex and link instead of edge. Some graph theoretical terms will be used (for example
parent-child), which will express essentially the same thing as they do in graph theory.

      Node: A synonym for node is mobile host. The graph theoretical equivalent is
      Neighbor: Nodes a and b are neighbors if their radio transmission range is longer
       than the distance between them.
      Link: Every kind of link between node a and b is denoted [a, b]. The graph
       theoretical equivalent is edge.
      Preference of a neighbor: A node that joins a tree prefers a node in the tree
       which becomes the joining node’s parent.
      Parent-Child: If there exists a link between neighbors p and n, and n has
       preferred p, then p is said to be n’s parent. N is p’s child.
      Grandparent-Grandchild: If c is a child of g and n is a child of c then n is said
       to be a grandchild of g. There can also be many more Parent-Child relationships
       between n and g.
      Interlink: A link that connects two nodes in different trees.
      Extralink: An extralink can exist between two subtrees. Whether an extralink
       exist is determined by a subroot which is currently forwarding a message. If the
       subroot’s tree contains a node with a neighbor in another subtree, then this node
       has an extralink. In figure 5-1 subroot 2 views the links [4,3] and [4,5] as
       extralinks but root 1 does not. This is because node 4 and 3 belong to root 1’s tree.
      Update: A message sent by a node whose subtree has changed (i.e. a child has
       moved out of range or a new node has joined the subtree and an update was

        therefore received). The update will propagate to the root, traversing every
        preferred link and every node adds itself and the updates it itself has received so
        far. When the message reaches the root, every node will “know” its grandchildren.
       Hello message: A message sent from a node to its neighbors when its state
       Route Query Message (RQM): A message sent by the source node to find a
        destination node
       Shallowness: If a node n has a route containing fewer hops to the root than
        another node q, then n is said to be a shallower node. A synonym for shallow in
        this text is high-level node.
       Next-hop: a routing table entry that indicates the next node on the route towards
        the destination.
       Branch: In this text a branch is a single loop-free path from a grandparent to
        grandchild. This path is used to forward to nodes with extra- or interlinks. These
        can be discovered because of the updates (section 5.4.1).

5.2 Introduction to TRP

TRP defines the network as a tree or a collection of trees that have developed
independently, and which can be joined together at later time by so-called interlinks. An
interlink connects two nodes that find that they do not belong to the same tree. A root is a
node that booted and did not find other nodes in its vicinity. When a node finds that it is
in the vicinity of other nodes, belonging to a tree, it will join this tree by associating itself
with a node that has a route that contains the fewest hops (shallowest) to the root. This is
possible because every node keeps track of the level it is on and informs the new node
about this in a hello message. The shallowest neighbor of the new node will form its
preferred link towards the root. Every node sends local information to its preferred
neighbor whenever it changes in an update message. The local information that a node
sends contains a list of the node’s neighbors, itself and the lists that was received from its
children. As this is done in every child-parent relationship, it will result in dissemination
of information in a controlled way and every subroot of every subtree knows which nodes
belong to its subtree. Therefore, the root’s routing table contains routes (knows next-
hops) to every node and can calculate which nodes have interlinks to other trees. To
clarify this, there is a distinct loop-free path from every leaf to the root through which
periodic updates are sent and the updates accumulate at every level of the tree as nodes
add themselves to the list. In this way a partial routing table will be set up at every node
in the form of a tree in which every subroot knows which nodes belong to its subtree.
This tree of preferred links is needed in the attempt to prohibit network-wide searches
when a node needs to be found by using a "divide-and conquer" method. Since every
node (subroot or root) knows which nodes are located in its subtree, it can deduce that a
route query does not have to be forwarded to any particular branch in the subtree at all. In
the case that there is a extra- or interlink in a forwarding subroot’s subtree then the path
to the node with the link can be found and forwarded to. Every "up cast" (towards the
root) of a message, containing a route query will increase the probability that a
grandparent will have a route to the destination node, and is able to answer the query.

A route query message (RQM) is a message that indicates a query of route from the
initiator (source) of the query to a destination node. RQMs are sent to the preferred
neighbor but also through extralinks, interlinks and to branches that contain extralinks or
interlinks. The extralinks are so-called because they have to be omitted when the network
topology is viewed as a tree, in order to set the paths for the updates to travel (see figure
5-1). It is then this tree view that forms the basis for the divide-and-conquer scheme
which can be used in forwarding decisions. The extralinks are links to neighbors that are
not preferred. This must not be understood that the extralinks would be dropped
altogether. They are still used to forward data messages and route queries because
otherwise discovery of shortest path could not be guaranteed. Therefore the tree structure
can be taken advantage of in certain situations.

TRP uses a semi proactive (table driven), semi reactive (on-demand) approach. It is
proactive because of the updates that are sent whenever a change in the routing table
occurs (i.e. a node receives a new update or a link is broken to a neighbor). On the other
hand if a node demands a route to a non-(grand) child the protocol will have to react with
the discovery process and issue a discovery control message. A fundamental idea in TRP
is that every network can be seen as a graph or as a tree if strategically chosen extralinks
are disabled in certain situations.

                        1                                         1

              2                  3
                                                              2          3

                                     5                  4                    5

                        Graph view                           Tree view

                                Fig. 5-1: Views of the network.

5.3 Tree Construction - Routing

A new tree is created when a node boots and finds that it is not within radio range of any
other node. At this point the node will declare itself as root and create a treeID with
which the tree is identified when inter-tree routing occurs. Therefore, nodes can detect
interlinks when receiving messages containing different treeIDs than their own. The tree
will grow as other nodes approach the tree or boot-up near it, depending on the length of
the radio range. A new node that is connecting to the tree will choose its shallowest
neighbor as its preferred neighbor towards the root. Links that are not preferred by any
node are called extralinks and are used in forwarding situations. Over time a tree will be

constructed which consists of preferred links and because of the preference of neighbors
close to the root, a tree as shallow as possible is constructed. The shallowness in turn,
implies that known paths are as short as possible. In figure 5-2 the new nodes are
presented in a differing color and extralinks are dashed. When the root is informed by the
MAC layer that it has radio contact to node 2, it will send a hello message, containing its
status, which is root, treeID and depth. Node 2 sees this as satisfactory and will
communicate the fact that it joins the tree, which is registered by root 1 and it then sends
an acknowledgement message to node 2. Node 2 receives this and calculates its depth as
the parent's depth+1. When node 3 boots and receives the same piece of information and
additionally a hello message form node 2, it will decide that its preferred link will be to 1
since it is at depth 0 and node 2 is at depth 1. If a node has two just as deep neighbors like
node 4 has, one of the shallowest neighbors can be preferred randomly.

                 1                            1                              1

           2                          2              3                 2            3


                                    Fig. 5-2: A growing tree.

Thus, after these operations are completed, node 1 will know that its tree consists of
nodes 1, 2, 3 and 4, because node 4 informs node 2 of its existence, node 2 will relay this
information to node 1. Therefore node 2 knows of child 4, node 3 has no children in its
table, but is aware of the extralinks because the MAC-layer keeps it informed about
neighbors. The update messages concerning tree members will be sent from any node,
when it detects a new child. Thus, the detector initializes the update procedure and sends
such a message which accumulates at every node on every level in the tree. This means
that every node on the path up from the detector to the root, will detect this change, as
they will all receive new updates. Every node adds itself and the updates that were
received from each of its children. The updates also contains the neighbors of every node,
this is so that extralinks can be detected by a subroot that has to make a forwarding
decision (RQM forwarding will be explained in section 5.4).

The interlinks provide a way for two trees to communicate. An interlink (Fig.5-3) is set
up only if two non-roots in different trees move into radio range of each other. If one of
the nodes is a root, it will include its tree with the other tree. This will help to keep the
amount of trees low and maximize the knowledge of roots and therefore minimize
message complexity when a node needs to be found. If two roots come into the vicinity of
each other, the root with higher ID number will include itself with the other root.



                   2              3

                                                           6               7

                              Fig. 5-3: An interlink between two trees.

The former paragraph specified how nodes associate themselves with other nodes when
joining a tree. Now, we shall see how breakage can occur. When a mobile node is moving
away from its neighbors (or powered down), some of the links to them might break.
Different types of link breakage can occur in an ad hoc network. The breakage type is
defined by the role of the node to which a link breaks and will require different measures.
A few examples will make this clear: A node moves around in the tree if its relative speed
is higher than others or moving in a opposite direction than others. A node moving
towards the root will make its way up the tree levels until it is a level 1 node. When the
node has passed the root it might seem that it should become root. This is not the case,
because, the tree is only a conceptualization of the physical network. The node will in
fact remain a level 1 node, although it is on the opposite side of the root, compared to
where it was before. If there are other nodes on this side, the node's level will again
increase as it moves away, otherwise it loses contact to the tree. A node moving around in
a tree will cause changes in its parent's and children's routing tables. The different
changes are explained below with help of figures 5-4 and 5-5.

                          1                                                    1

                   2              3                                    2       5   3

              4           5               6                    4                       6

                                   Fig. 5-4: A node moves “up”.

In figure 5-4 node 5 is moving towards the root and at some point when node 5 is passing
node 2, it will receive a hello message from the root, saying that it has a level 0 neighbor

(the hello message is sent when the link layer indicates a new neighbor). This will cause
node 5 to change its preferred link to the root and become a sibling of node 2 and 5, and
generate possible extralinks to these if they exchange hellos. Node 2 will be informed that
node 5 is no longer a child of it. The parent has to be explicitly informed of this by means
of a un-association message. This is because the MAC layer information does not contain
the fact with whom the child is associated. In this particular situation node 5 is still a
neighbor of node 2 and the old update message would still be relied on, if the former
child does not explicitly delete it. The explicit delete message causes node 2 to remove 5
from its child list and send an update message to the root. If node 5 had any children, the
subroot of the children would become root if it does not have any other links than those to
its children. If a link is broken before the un-association message arrives at the former
parent, it can remove the former child when the MAC layer indicates that.

                         1                                        1

                   2            3

                                                                  5      2        6
             4           5           6

                                 Fig. 5-5: A node moves “down”.

The situation in figure 5-5 is similar to the one in figure 5-4 where new siblings are
formed, but here node 2 is moving in the other direction. Node 2 will become a sibling of
6 and 5, leave its former subtree containing 2, 4 and 5. Subroot 5 will prefer subroot 3
because it is the shallowest of its neighbors. Changes in tree movement can be seen from
three perspectives. The moving node that becomes disconnected and will begin taking
measures to find a neighbor with the lowest depth and associate with that neighbor, the
perspective of the former child, which will use one of the former extralinks or interlinks
as the new preferred link. If no such link exists, then it will form a new tree. The third
perspective is the perspective of the parent of the moving node. Little has be done by the
former parent, it should remove the invalid update when either it receives a hello saying
that the parent is no longer preferred or the child moves out of range, which is indicated
by the MAC layer.

One special breakage situation can occur as the link from level-1 nodes to the root breaks.
The root can be seen as a potential single point of failure, warranting a secure scheme to
be supported for choosing a new root when it fails. In TRP this is implemented in the
following way: When a root is moving away from its children, the first child to detect this
will become the root of a new tree (consisting of itself and its subtree). This will only be
for a brief moment if the new roots siblings are still in its vicinity. After that the new root

can either include itself with the old tree if its former level-1 siblings are still near by.
Therefore, every level-1 node will first become root for a while, but since the there is a
rule that roots should try to include themselves with other trees, they will do so, except
for the last level-1 node to experience breakage to the original root, will remain as root in
the new tree. This is due to the fact that a root cannot associate with its children, and the
last node to experience breakage has no other neighbors but children. Figure 5-6 shows
how root link breakage can occur.


                                                                       2            5
          2             3                2

    4           5                   4             5

                                    Fig. 5-6: Change of root.

Let us say that node 2 is the first to detect that the root is no longer within its radio range.
Node 2 will declare itself as root, but shortly after, include itself with node 3, because of
the rule. Node 2's children follow with it. If, in fact, it is the root that is on the move,
node 3 will also notice what has happened and do the same except it cannot include itself
with 2 or 5 because they are children of 3, consequently it will remain as root. There will
not be a great delay before the new root will have the same information as the former root
since nodes 2 and 3 had the second most information about the tree. Therefore, when
node 2 sends its update to the new root 3, its view of the tree will be complete,
eliminating the single point of failure problem.

One concern that arose while developing the protocol was that the updates would become
excessively large when every node adds itself and its neighbors to the message. If also,
many nodes are neighbors, the same nodes will be mentioned several times in the same
update. It was clear that a scheme for reducing the size of the updates had to be
introduced. To address this problem a scheme proven useful in many protocols was
devised in the form of incremental updates. In this way, the updates informing of the
following events can be reduced to the size of a hello message: If a node leaves a subtree,
only a message indicating this occurrence has to be sent to the root. The message must
also include which other nodes (grandchildren of the absent node) are inaccessible. This
task is performed by the parent that detects the absence of one of its children, which also
informs every node on the path from itself to the root, by sending an incremental update.
Another event requiring only an increment is the joining of a new leaf node. In this case
the update only contains the leaf node and its neighbors. The incremental update method

is not applicable in the following situations: When a subroot associates with a new parent
in the tree and its children “follow” (still within radio range) with it. In this case it is clear
that the parent might not know about the children of the moving subroot and thus has to
be informed about them with the help of a full update. Had the children of the re-
associating subroot lost contact with it, an incremental update would have sufficed.
Naturally, a full update has to be sent by a level-1 node when it detects a new root since
the new root in its former position as a level-1 node, had only information about its
subtree. In this case the transmitted full update only affects a very local part of the tree,
that is, the bandwidth of the link between root and a level-1 node. There is also another
occasion when the full update has to be used and that is when a root includes its tree with
another. Here, the whole path from the node with which the former root includes its tree,
to the root is affected and a degradation of the available bandwidth might occur. While
the updates consume bandwidth they also have positive effects, for one thing they reduce
the route discovery delay dramatically. This is especially true as the RQMs travel towards
the root, because higher-level nodes have more routing information about the tree. So to
give a summarizing generalization of when full updates have to be used, it can be said
that these are required whenever a non-leaf node associates with a new parent. This
causes the parent to send an update, but its update on the other hand can be incremental in
the respect that it sends only an update concerning the new child’s subtree. For example,
this happens when a root of a tree associates with another. In this case, the node with
whom the root includes its tree will only have to send an incremental update that contains
the nodes of the including tree and leave out its other subtrees from the update.

5.4 Forwarding

In this section, the forwarding of TRP will be discussed. This touches both forwarding of
RQMs (control messages) and data messages (non-overhead). Actually, the forwarding of
the RQMs is part of the routing stage because that is what we try to establish, a routing
table entry for one or more destinations. Nevertheless, these messages are being
forwarded and it seems natural to have them in the same section, which makes it easier to
compare the two.

5.4.1 Forwarding of RQMs

When a node wants to send a data message to a destination node, it first checks whether it
has a route entry (next-hop) for the destination. The next-hop can be found by checking if
the destination is among the node’s neighbors, children (in updates) or if there is a
routing table entry. The entry can be recorded when the node previously issued a query
and received an answer, or when it forwarded someone else’s RQM. When forwarding
such a message, an intermediate node can extract a next-hop for the source. If the node
does not have an entry for the destination it wants to send data to, it will send a RQM to
all appropriate neighbors. The appropriate neighbors are the preferred neighbor,
neighbors connected by extralinks and to branches (the path to the extralink) that contain
extralinks. An extralink in a branch is detected in the following way: The subroot will

check the update messages gotten from its children to see if any of the nodes in its subtree
has a link to a node that is not included in the subroot’s subtree. In practice, every node
adding itself to an update message will mark itself as a member of the tree and put its
neighbors in another section of the message. The nodes of the neighbor section can then
be compared one-by-one to the member nodes and whenever a match is not found, an
extralink is detected. The subroot will in effect calculate the next-hop to the node with the
extralink which will also be done by the next-hop node and so on until the node with the
extralink is reached (the whole branch is discovered). If the node that is being forwarded
a RQM neither has an entry for the destination, it will also forward the message to its
appropriate neighbors. On the other hand, if it does possess the requested route, it can
acknowledge the RQM and send it back to the source. This activates the route that was
discovered up until the RQM was acknowledged, concatenated with the acknowledging
node’s route. The neighbor of the destination is bound to be able to answer the query at
the latest. To maximize dissemination of routing information, nodes that are forwarding
unacknowledged RQMs record a next-hop for the originator and when forwarding
acknowledged RQMs a next-hop for the destination can be recorded.

 Header:        Type Forwarding_node Originator        Destination      Msg ID           Hops_traversed

 Size (bits):    3      log 2 #nodes    log 2 #nodes     log 2 #nodes    See sect. 5.4.2 See sect. 5.4.2

                                        Fig. 5-7: RQM format.

The RQM message format is shown in figure 5-7. The first field identifies message types.
The originator and destination fields are self-explanatory and used for the purposes
explained above. The hops_traversed field is used to discriminate between copies of the
same message that have taken different routes and will help reduce the message
complexity further. Every node that forwards a RQM adds one to this field (an
acknowledged RQM will contain the number of round trip hops when received by the
initiator). If it has not seen this message or if it has seen it, but the hops_traversed is less
than in the previous copy, it will still forward it. This applies to acknowledged and
unacknowledged RQMs. In figure 5-8 a simple scenario is given, which explains how a
node is found.




                        5            6          7              8

                            Direction of the unacknowledged RQM
                            Direction of the acknowledged RQM

                                    Fig. 5-8: RQM broadcast.

Here, node number 5 tries to contact node 4 and does so by sending a query. It sends the
message to node 3 which finds in its received update messages that a branch beginning
with child node 6 has an extralink. As node 6 receives this it can immediately answer the
query by sending an acknowledged RQM back the same way it came. This is easy since
every node that the RQM traversed, will have recorded a next-hop for the originator. This
rule, to forward RQMs to subtrees with extralinks ensures that a shortest path is found,
which would not be possible by forwarding only to preferred neighbors. The message
will also reach the root at some later point which can provably answer the request since it
holds all update information about the tree. The node that answers the query, must also
add the its distance to the destination, to the hops_traversed field in order to provide a fair
basis of comparison for a node that must decide to forward the acknowledged RQM or
not. Therefore the root adds one (for the link [1, 4]) to the current hops_traversed which
is three, node 2 adds one for the hop [1,2] amounting to five. As node three is forwarded
this message hops_traversed value will be six. This is more then the other copy which
came from node 6 and therefore dropped by node 3. This means that multiple routes are
not used by the protocol at the moment. The same rules for making forwarding decisions
when extralinks are present apply to subtrees with interlinks.

Figure 5-8 is an overly simplified picture and does not show the amount of saved
message complexity that can be achieved with TRP routing. It is feasible that some of the
nodes 5, 6, 7 or 8 would have large subtrees beneath them. Nodes in these subtrees would
not have to be contacted at all in order to find the destination node.

5.4.2 Preventing Loops

The RQMs possess another important property because of the field hops_traversed. This
field will guard against message loops in the following way. Every node records a

message the first time it gets it. If it is received again, then the message will have traveled
a loop and it will have a greater hops_traversed value and therefore discarded. So, the
message will actually be allowed to travel once through a loop and then stopped. The
same argument for loop-free routes can be argued for the acknowledged RQMs since the
hops_traversed value continues to accumulate after it is acknowledged. Because RQMs
are not allowed to travel loops from this follows that routes cannot be set up that contain
loops, therefore, data messages cannot loop either.

Since the header field containing the RQM ID is finite it will roll-over at some point and
start over. This has to be taken into account when specifying how long a forwarded RQM
is to be stored in order to detect loops and obsolete messages. If they are stored too long,
a situation where unseen messages are dropped can occur. On the other hand if the
message is stored for a too short a period, it might happen that seen messages are
forwarded again.

As a starting point it might seem to make sense that both the storage time (st_time) and
the time for the number to roll-over (ro_time) are of the same length. According to figure
5-9 the RQM will be deleted at the same time as a new RQM with the same ID arrives. It
might be possible that the next time the source sends a new message, it will have acquired
a shorter, faster route, making the message travel with lesser delay. This means that we
cannot store the message over a time that would correlate to the number of hops that the
message has traveled. There is a factor from which we can begin to reason, namely the
propagation delay of a packet. The nodes will have to store entries containing the source
address, message ID and destination address in order to detect seen messages.

                                                             msg A at time
         msg A at time T                                     T+delayA

           1                              network                            2
                                                                                 msg A deleted at time
          msg B at time                                      msg B at time
          T+ro_time                                          T+ro_time+delayB

                           Message A and B have the same ID number, ro_time=st_time

                                    Fig. 5-9: Message propagation.

From figure 5-9 it can be seen that if the maximum time to store an entry is equal to the
time it takes for the message ID to roll-over the entry will be deleted at the same time a
new message with the same id arrives. But this is to assume that both messages will
propagate through the network with the same speed. It is possible that the first message A
is traversing a route that is congested and will be heavily delayed while the second
message B with the same ID travels much faster. This problem is equivalent with the

problem that arises when the source finds a faster route. In this case the time for
(T+delayA+st_time) > (T+ro_time+delayB ) meaning that the message A will still be
stored as B arrives with the same message ID. This causes an unseen message to be
dropped. It is obvious that an assessment of the largest network thinkable has to be made
and the network delay (net_delay, the delay that could be experienced in the longest route
in a maximum sized network) of that. One should not make the mistake of thinking that
message A could be deleted at time (T+delayA ) because node 2 has no way of knowing
when that is - it does not know when the message was sent. This is why the destination
must wait a maximum network delay time (net_delay) before deleting the message. The
source has to be even more cautious and never assume that the message will reach the
destination with the same speed every time (as the example above indicates). To deal
with this the ro_time has to be made twice as large as the net_delay.

Figure 5-10 and 5-11 will further demonstrate this. In this example we assume that worst
case buffering delay at every node is 2 time units and traversal of a link “costs” 1 time
unit. Since the longest loop-free path is 5 the net_delay is assessed to be 15 time units
(assuming that the message is not buffered at the source).

                             6                       5                              msg A at time

    1                                                                       4       msg A deleted at time

 msg A at time               2                           3                          msg B received at time
 T=0                                                                                0+15+1+1+1=18
                           msg A at time                msg A at time
 msg B at time             0+1                          0+1+1+1=3                   When receiving B
 0+15=15                   buffered 1TU                                             before A is deleted
                                                                                    causes B to be wrongly
                           msg B at time                msg B at time               dropped.
                           0+15+1=16                    0+15+1+1=17

                 Message A and B have the same ID number. Msg A is delayed at node 2 but B is not.

                                    Fig. 5-10: Incorrect storage time.

                               6                       5                          msg A at time

    1                                                                        4    msg A deleted at time
                                                                                  (30 in worst case, if some
 msg A at time                 2                           3                      other route than 1-2-3-4)
                                                                                  msg B received at time
                              msg A at time               msg A at time
 msg B at time                                                                    0+30+1+1+1=33
                              0+1                         0+1+1+1=3
 0+30=30                      buffered 1TU
                                                                                  A is deleted before B
                              msg B at time               msg B at time           arrives, this is OK even
                              0+30+1=31                   0+30+1+1=32             if msg A would have
                                                                                  been delayed for the
                                                                                  max time 15
                                      Message A and B have the same ID number.
                                       Msg A is delayed at node 2 but B is not.
                                       Fig. 5-11: Correct storage time.

The ro_time has to be this long in order to take the possibility that the first message is
delayed the maximum amount of time on the network, and stored for 15 time units at the
destination. From figure 5-11 it can be seen that even if message A experiences the
worst-case delay, it will be deleted when message B arrives with the same ID. This means
that it is deleted at time 30 and that the other message cannot be received before that. The
following pseudo code outlines the procedure for forwarding RQMs:

receive RQM r.

IF a r’s ID and originator matches some entry,

                 add next-hop and distance for originator in r, to routing table.

                 IF I have entry for destination d,

                                   add the distance to d to the RQM hops traversed.

                                   send acknowledged RQM r to originator.
                                   add one to hops_traversed.

                                   forward the RQM to appropriate neighbors.

                 discard r.

The algorithm for forwarding an acknowledged RQM is almost the same except now a
next-hop for the destination is added to the routing table. At this time the forwarding
node will have a next-hop for the originator unless breakage has just happened and
operation will have to stop. A transport protocol will be needed to make this operation
reliable. The acknowledged RQM thus follows the shortest route back provided that all
the unacknowledged RQMs have reached the destination, traversing every possible path.
This might not always happen right away, but since nodes continue to forward seen
messages with shorter hops traversed, it is bound to happen sometimes. So it does not
actually matter if the first acknowledge RQM takes a longer path. The hops_traversed is,
naturally, copied from the unacknowledged RQM to the acknowledged RQM, and will
continue to accumulate as it is forwarded back to the originator. This means that also
acknowledged RQMs can be dropped if multiple copies arrive at a node that has seen one
with shorter hops_traversed. And as stated before the intermediate node that
acknowledges the RQM also has to add the distance from it to the destination to the
hops_traversed header field.

5.4.3 Forwarding of Data Messages

A data message is a message used to carry the users information. For these messages
routes are set-up by RQMs, therefore the data messages follow paths between the
originator of the RQM and the destination as long as the route is not broken. The path is
broken when one node in the path moves out of radio range of the previous node. A node
in the route detects breakage by checking that the next-hop is still in the set of neighbors
provided by the MAC-layer before forwarding the data message. It is assumed that the
message gets transmitted and received, and left to the higher layers to achieve reliable
end-to-end transmission. More reliability can be achieved by trying to overhear that the
node that was forwarded a packet also forwards it itself if the MAC-layer has this ability.
Hop-by-hop acknowledgements are also possible although not used at the moment. TRP
does provide a way for other nodes on the route to be notified of the breakage. The node
that discovers the breakage sends a “destination unreachable” message that propagates
back to the originator of the data message and will at the same time delete every next-hop
entry at every node for that particular route. Thereafter the source sends a new route
query, and can try this for several times before giving up. Naturally, a data message can
be sent to a neighbor or a (grand) child in a tree without querying at all, because of the
updates. Because the neighbor of the destination node can at the latest, acknowledge the
RQM, the discovery process provides no information about the network to the
destination. Letting the destination record a next-hop for the source of the data message
can help this.


If we assume that at some point in time, the complete ad hoc network could be freezed
and represented by a connected graph G=(V, E) with vertices V (nodes) and edges E
(links). It is also assumed that all routing information has converged then a proof of
shortest path discovery can be given. In a network with mobile nodes one can never
guarantee full connectivity at all time. In the proof we will use the graph theoretical
definition of a tree, which is the following:

(1)          - In a tree, only one loop-free path exists between two nodes.

We restate the rules for forwarding route query messages if the forwarding node does not
have a route to the sought node. Points 2 through 4 are concepts from the routing
algorithm which will be used to prove discovery of shortest path from a global point of
view of the network in a constructive manner. The RQMs are forwarded to:

(2)          - The preferred neighbor
             - Extralink and interlinks
             - Subtrees with extralinks or interlinks

The following things are also reminded of:

(3)          - Updates are sent along the tree (preferred neighbors) from leaf nodes to
             the root. This means that every subroot knows the members of its subtree.

Every RQM is a tuple with the elements <ss, ms, hs> received by node i are stored in Ti
regarding a RQM sent by source s. ss is the node ID integer of the source of the RQM, ms
is the message ID integer and hs is the hops_traversed value corresponding the number of
edges on the path between s and i.

(4)          Say that node d receives RQM <sr, mr, hr> from r.
             If<s, m, h>Td sr=s  mr=m  hr<h then the RQM is forwarded and
             <sr, mr, hr> replaces <s, m, h> in Td.

             Or if < sr, mr, _>Td then <sr, mr, hr> is forwarded and inserted into Td.

If we would view the network as a tree, one path is guaranteed but not necessarily the
shortest (1). The network is only viewed as a tree in the first part of the routing phase,
that is, how the nodes align themselves in order create a tree which branches will carry
the updates. When the second phase of the routing stage is initialized, the network has to
be viewed as a graph again, so that the shortest path is found. This is when the extra- and
interlinks are used.

Let [x, y] is an edge from node x to node y.

In a path with n nodes, P(0, n-1) is a path with edges {[v0, v1], …, [vn-2, vn-1]}EP where EP
E and the nodes v0 to vn-1 are a subset of V. Each node is enumerated so the identity of
every node is known.

c(P(0, n-1)) returns the cost for traversing path P(0, n-1) with edges EP and
c(P(0, n-1))=|EP|=n-1 (The “cost” of traversing one edge is 1).

min(SP) can choose the shortest path (least edges) from a set of paths SP because of (4)
where every traversed path (by RQM) longer than the shortest is dropped.

D-E tree is a dead-end subtree DE=(VDE, EDE) where VDE V and EDE E with no
edges of the following form: [t, e] where tVDE and eVDE (no extra- nor interlinks).
The subroot of the subtree is the node currently forwarding the RQM will calculate
whether a subtree is a D-E tree.

Theorem 1: Every root’s routing table contains the shortest route to every node in its

Proof 1: Every new node aspiring to connect to a tree chooses the shallowest node from a
set of neighbors for association. The updates contain the shortest routes. (Analogously:
every subroot knows shortest paths to all nodes in its subtree)

Theorem 2: The shortest path from a source node s to an arbitrarily chosen destination
node d can be found if s and d belong to the same network.

Proof 2: The following 3 steps prove how the shortest path is constructed. Nn denotes the
set of neighbors of n. M is a set of nodes. L is a set of edges.

1. Set M={s}
2. For every node m in M, add every edge [m, g] where g Nm to the set L, and also add
g to M if the following is true:
               -2a. [m, g] is not an edge leading to a D-E subtree which does
                not contain d (this is known because of Proof 1).
               -2b. [m, g] L
               -2c. If 2a and 2b is true but g M then add just [m, g] to L.
3. Recursive step: Go to step 2 if d is not in M.

From L, every distinct path in SP={P1(s, d), P2(s, d), …, PN(s, d)} from s to d can be formed
by constructing different combinations of elements in L.
From SP can min( c(P1(s, d)), c(P2(s, d)), …, c(PN(s, d)) ) be extracted which is the shortest
route because of (4).

In practice TRP has a property that prevents the shortest path of being used in certain
situations. For instance, if one node n has in its cache, an old valid path to the destination
while a newer shorter path might have been formed since then. Since n will not forward
the RQM, but rather acknowledge with the old path in its cache, a longer path might be
used. Because of (2) the RQM will traverse every link but those that are in D-E trees
which do not contain the sought node. D-E trees and the members of the subtree can be
detected because of (3).

Example of proof 2 – find a shortest path from node 4 to node 1 in figure 6-1:

                                             add start node 4
                1                            Node 4:
                                             - add edges [4,2], [4,3], [4,5]; nodes 2, 3, 5
                                             Node 2:
        2               3                    - add edge [2, 1]; node 1 ([2,4] is already in L)
                                             Node 3:
                                             -add edge [3, 1] [3, 5] (use rule 2c because 5 and 1
                                             is in M)
   4                        5                Node 5:
                                             -nothing to be done; ([5,4][5,3] is in L and subtree
                                             of nodes 6 and 7 is D-E)
                                             Node 1:
                                             -nothing to be done
                    6               7

Fig. 6-1: Two shortest paths are found between node 4 and node 1.

At this point L={[4, 2], [4, 3], [4, 5], [2, 1], [3, 1], [3, 5]} from which non-cyclic paths
P1(4, 1)= {[4, 2], [2, 1]}, P2(4, 1)={[4, 3], [3,1]} and P3(4, 1)={[4, 5], [5,3], [3,1]} can be
combined. Min(P1(4, 1), P2(4, 1), P3(4, 1)) yields P1(4, 1) and P2(4, 1) which is c(P1(4, 1)) =
c(P2(4, 1))) = 2.

Lemma 3: The discovered routes are loop-free.

Proof 3: Every message that traverses a loop will have a greater hops_traversed value and
therefore discarded after the loop is traversed.

Corollary 4: D-E trees that do not contain the sought destination d are never searched.
(RQMs are never disseminated in D-E Trees).

Proof 4: In proof 2 step 2a will ensure that no edges from a D-E tree not containing d,
will ever be put to the set L.


A simulator should provide information about how the protocol performs under varying
strain. The strain increases when the amount of nodes, network activity and movement of
nodes increases. Many ad hoc routing protocols are designed so that increase of inactive
nodes affects overall performance only marginally (reactive) in contrast to proactive
protocols that maintain a route to every destination. If, on the other hand, new nodes are
active, sending messages, then greater strain will be put on the network. There is also an
upside to having more nodes in the network and that is improved connectivity. The
second variable is a natural one, when network activity increases (more messages are
sent) the routers will have to work harder to keep up. The former two variables are such
that ad hoc and static networks have in common, the third one they do not have in
common which is node movement. In ad hoc networks node movement is of course the
main thing to resolve. In TRP node movement generates strain because old entries in
routing tables have to be updated by sending new queries. As the most interesting factor
in ad hoc networks is mobility, the results will be portrayed as a function of the speed.
The results should at least show control message overhead, amount of packets delivered
and route discovery latency during increasing speeds of nodes. Data messages (non-
overhead) will be sent to randomly chosen nodes, which will result in route query
(control overhead) if a route is not known, but only the data messages delivery rate will
be recorded in this test. The opposite, is of course recorded in control message tests, that
is, how many route queries has to be sent during increasing speeds.

7.1 A Technical Description of the Protocol Simulator

The simulator of TRP was implemented to have layered architecture, with a MAC layer
and network layer. The MAC layer functions are not implemented in a realistic way (thus
called Virtual MAC), but are rather a way to provide services for the routing and
forwarding algorithm. These algorithms on the other hand are very realistic. All the nodes
are represented by processes that cannot communicate in any other way but sockets. In
the simulator, every piece of information that one node learns about another has to be
exchanged like real protocols by informing the neighbors. It might seem like it would
suffice to use the MAC-level information about the neighbors, but this is not always the
case. Since TRP stores information about a neighbor’s treeID and depth among other
things these should be informed as well. In order to minimize the amount of such
messages, these are only sent when a change in some node’s state occur (i.e. depth,
treeID or list of children). Thus, an entry concerning a neighbor is considered to be valid
as long as neighbors remain within range, which is confirmed by the MAC-layer.

The simulator was run on a AMD Athlon with a clock frequency of 1GHz and 256 MB of

7.1.1 The Virtual MAC Layer

The Virtual Medium Access Layer (VMAC) is something that was created to emulate a
layer-2 MAC protocol. The only thing that the rest of the simulator expects from it, is to
provide a lower-level addressing scheme with globally unique addresses and to keep the
network protocol informed of which nodes are within radio contact of the node itself. The
VMAC is simulated by processes that listen to a given port. Every process also "knows"
its position in a coordinate system. At start-up and each time a process or node (which the
process represents) moves, it will send its current coordinates to all other nodes which
calculate the distance between them in order to simulate the radio range. At this point
both will make note of what has happened and record the address of the other node in a
table. When one moves away from the other this will be detected by the non-moving
node, which tells the moving node that radio contact is lost, upon which both delete the
entry in the neighbor table. In a real implementation the MAC-layer would have some
sort of API to retrieve the information of neighboring nodes, but in this simulator the
neighbor table is made available to the routing algorithm.

Given the time-critical properties of a routing protocol, UDP was chosen for
communication between processes and a message informing movement will be sent to all
possible ports where a process could reside (this was done to simplify the programming
job). In fact the simulator could of course have been designed to use message passing or
shared memory, even the whole layer structure could have been omitted. The reason why
this was not done, was because we wanted to simulate a protocol a realistically as
possible, having components that real protocols have. Another reason for the chosen
structure was to make it as easy as possible to convert the simulator to a real protocol if
the need for that arises. So, for the purposes of the simulator, the port that a particular
process handles is the same as its MAC address (and a constant added to that, the routing
layer uses another port) and all the UDP packets needed for calculating routes are sent to

At this layer there is no need for a timer that indicates when an entry in the neighbor table
expires since a message will be received when a distance is too long. This would not be
possible in reality but the focus of the simulation is on the network layer and not MAC,
thus this simplification at this layer was allowed.

7.1.2 The Network Layer

As mentioned before the routing messages are sent on a different port than MAC
messages. Therefore, this port is used for the data and control messages. The same
program module is used to dispatch routing control messages and data messages. The
module is a thread that blocks if no messages arrive and loops as fast as messages arrive
when neighbors are transmitting.

The simulator does also contain another important thread, namely the routing thread.
Since in TRP routing is the equivalent to tree construction, this thread or algorithm
decides how the node should behave in different situations. The message dispatch thread
and the routing thread work together to make the node behave correctly. This is achieved
by letting the dispatch thread set the state of global variables so that the routing thread
can react to new information about the tree. For instance the dispatch thread might
receive a hello message saying that a neighbor’s depth has changed and that it is not the
shallowest neighbor anymore. This will be recorded in a table that is used for storing
information about the neighbors, similar the MAC neighbor table, but more details are
included, like the depth, treeID and state (is it a root). Since the routing thread evaluates
the shallowest neighbor frequently it will decide to associate itself with another neighbor
or if that is not possible, just increase its own depth according to its parent. Another
scenario could be that the preferred neighbor’s treeID changes as the root of the tree
includes itself with another tree. At this point, since the root’s state changes, it will send a
hello message saying that this tree has a new ID. This will cause every child of the old
root to do the same, thus spreading the news of a new root of the tree.

Before routing and forwarding decisions are made, the MAC information is checked that
every node in the detailed neighbor table is in fact still a neighbor. If not, the node is just
expunged making it impossible to take the node into account in the next calculation. This
arrangement actually eliminated the need for many timers that would expire whenever a
hello was not received on time and also reduces the amount of messages that has to be
sent because unchanged information is never sent.

The updates are also dispatched by the same thread and put in a table of their own. This
update table contains updates from all children and is used to assemble the node’s own
update. When this new update is assembled it is checked against the old one. If they
differ in any way, it is sent to the preferred neighbor (parent) which will go through the
same process. These entries in the update table are also valid as long as the child that sent
it remains a neighbor or an explicit un-association message is received.

The RQMs are also stored in a table, for checking purposes when a node receives a RQM
that should be forwarded. Before forwarding the message, the ID, originator and
hops_traversed fields are compared to every message in the table. If the message has been
seen and its hops_traversed value is greater then it is not forwarded. Because the
hops_traversed field is limited, the count will at some point roll over. This brings us to
the only timer that TRP has, that ages the recorded message. It must "age out" the
messages before a roll over has happened at another node. If this is not taken care of
properly, an unseen message will falsely dropped as explained in section 5.4.1.

7.2 Simulation Settings

For the simulation we choose the largest possible area, so that the network, with a high
probability, never becomes partitioned. We say that the network is partitioned if at least
one node is disconnected so that it could not even in theory find a route to every

destination. We did not want the network to be partitioned in order to receive the true
characteristics of the protocol. A partial network would incur worse results since the
nodes could never reach all other destinations. Therefore, in order to choose the suitable
area for 25 nodes with the radio range of 100 meters. We ran the simulator 20 times and
noted the initial position of the nodes. Every time a result yielded partitioned networks
we would decrease the size and try again. We stopped when all twenty runs yielded only
single connected networks.

                        Fig. 7-1: 25 nodes in a 400x400 square meter area.

In figure 7-1 one can see one of 20 runs, which show that at this size it is quite likely for
the network to be partitioned. Figure 7-2 shows another partitioned network even though
it is reduced to 350x350 square meters

                       Fig. 7-2: 25 nodes in a 350x350 square meter area.

We also tested 320x320 but that still sometimes left one node by itself, but when the area
was set to 300x300 the network was connected at every run and not partitioned in any
way. One example run can be seen in figure 7-3.

                       Fig. 7-3: 25 nodes in a 300x300 square meter area.

In the simulator nodes select a position randomly and start moving in a random direction.
The direction may be parallel to the x- or y-axis, or diagonally at a specified speed.

The VMAC was programmed in such a way that a conflict-free MAC protocol has to be
assumed, for instance CDMA with perfectly distributed codes so that nodes can transmit

at will. This is different from contention-based MAC protocols that use RTS-CTS
handshakes. In contention-based protocols nodes cannot transmit at will, before the
handshake is made. Since nodes can transmit when they want as long as they want, this is
why we do not have to take the sizes of the messages nor the transmission data rate into
account. In contention-based protocols simulators the time that it takes to transmit a
message has to be estimated (packet size/data rate) and other nodes must not transmit
during this time.

Congestion was not monitored specifically in the simulator, but the amount of lost
messages is proportional to the amount of congestion. Also, we did not set an artificial
receive buffer size for the nodes (processes), but instead, since real UDP sockets was
used, we let the receive buffer of the sockets model available storage space for packets to
be handled. In Linux the sockets receive buffer can be set with a command called
“setsockopt” and the default buffer size is 42080 bytes which was used in the simulator.

When the first RQM fails, that is, a time-out period has elapsed, a second RQM will sent
to try to find the destination. If the second attempt also fails, an error is reported that the
destination is unreachable and the simulator will count this as a lost data message because
it was never sent. Currently no route aging is used, which might contribute to higher
delay values. In route aging one has to be careful not to delete functioning routes. More
research has to be completed before a suitable route-aging scheme can be implemented.

While it remains unseen how TRP scales, it was shown that the simulator itself does not.
The overhead from communicating with UDP between 25-50 processes, not only at the
network layer but also at the VMAC layer made the simulator sluggish when simulating
more than 25 nodes. It was also noted that when running the simulator on a more
effective computer, the delivery rate improved. The same happened when we scheduled
more processor time for the simulator program (by using the nice command). This was
the reason for the relatively slow message rate, as more messages require more of the
hardware of the computer. The rate at which data messages are sent is 1msg/second
during a period of 30 seconds in real-time. The results were obtained by running the
simulator 10 times and then calculating the average value of the runs. The graphs also
show the standard deviation of the runs.

7.3 Results

The initial results of the simulator are promising. Figure 7-4 show how the delivery rate
of data messages behave, as the speed of the nodes are increased from 0 to 10 meters per
second. The delivery rate decreases evenly until 5 m/s is reached, this seems to be a point
that is reflected in the other results as well.

                             Avg. delivery rate of data messages

                120 %

                100 %

                 80 %

                 60 %

                 40 %

                 20 %

                        0      1     2     3     4     5    6     7        8   9   10
                                                 Speed m /s

                               Fig. 7-4: Delivery rate of data messages.

                                     Avg. RQM rate per node







                         0      1     2     3    4     5      6   7        8   9   10

                                            Speed, m/s

                                          Fig. 7-5: RQM rate.

The graph in figure 7-5 shows that very few RQMs are sent even at high speeds. The
average time for nodes to find routes to destinations is presented in figure 7-6. This graph
seems to be more independent than the others, although a varying increase in delay

                            Avg. route discovery delay per node









                        0         1       2       3        4       5       6       7       8   9   10

                                                      Speed, m/s

                                  Fig. 7-6: Route          discovery delay.

                            Total amount of relayed control messages







                              0       1       2        3       4       5       6       7   8   9   10

                                                      Speed, m/s

                             Fig. 7-7: Relayed             control messages.

Figure 7-7 shows an interesting statistic of relayed control messages. In this statistic
every relayed control message is counted as a new message. So, for instance, if a RQM is
sent and the sender has two neighbors and the neighbors also have two neighbors then a
total amount of 6 control messages will be counted. In the same way, if a ”destination

unreachable” message is sent from a node to another through a route that contains 5 links
then the message will count as 5 messages not 1. This will enable us to see how RQMs
for example “reproduce” when multicast to appropriate neighbors.


Every graph shows that at speeds from 0 to 3 m/s the performance worsen, but at 5 m/s
every curve shows improving results up until 8 m/s. It is possible that 5 m/s is a speed at
which it is less likely that both the first and retry RQM fails to find the destination. In
other words, a node might have connected to new neighbors after the first RQM was sent.
Although the MAC layer of the simulator is not realistic, it is not unrealistic to assume
that the MAC layer could provide information about neighbors, needed to omit periodical
hello messages and updates. If periodical hello messages were used, this simulation
would have worse results.

Although good results were obtained with respect to the delay characteristic, even smaller
delays could be obtained with active route aging and deletion. It is hard to estimate when
a route is not functional anymore (without testing the route) and should be deleted so that
these routes are not used to answer route queries. There is not a lot of information to base
accurate estimates on other than time.

There will always be a maximum speed that a mobile node can travel and still stay
connected to an ad hoc network. If the delay of the route query is greater than the time a
node stays in a neighborhood then the node will never be able to communicate because
answers to queries will always be sent to the wrong place. If further test show that TRP is
effective and scalable then multicasting will also be implemented. This issue is, however,
completely open at the moment.

8.1 Summary

8.1.1 Scalability

Scalability issues have to be considered especially carefully in ad hoc protocols. Not only
will the MAC protocol be under higher strain when there are more nodes in the
neighborhood but the network protocol also has to be made capable of handling large
amounts of nodes. As the data rate in wireless networks is not yet at the same level as that
for fixed networks, we have to take care that these are not flooded with unnecessary
control messages while at the same time the need for frequent use of these is greater than
in fixed networks due to mobility. As for MAC protocols the medium access method will
play a large role in providing better scalability. When contention based protocols are used
and the neighborhood of a node grows it is clear that throughput will degrade. It is also
clear that at some point the competition for the medium will be so great that no quality of
service can be guaranteed. This calls for approaches were nodes can transmit without
contention in so-called collision-free protocols. If these are the MAC protocol of the
future will be determined, among other things, by how effectively the spreading codes
can be distributed.

The largest factor behind the Internet’s great scalability is aggregation. The whole
Internet is partitioned into autonomous systems (AS) and AS are partitioned into
networks. Only the information relevant to finding a host in the right network is
propagated outside the network and information relevant to finding the right network is
propagated outside the AS (to the backbone). It is harder to provide such aggregation in
ad hoc networks, but not impossible (see hierarchical protocols 3.3). If no aggregation
methods are used, there will always be a risk that control messages will start consuming
so much bandwidth that the network will become unusable.

As we saw in chapter 2 (MARCH) and 4 (TCP-BuS) good results were obtained by
letting protocols at different layers interact and access information that can make ad hoc
networks more scalable. Consequently many believe that this is the way to continue the
evolution of ad hoc protocols as almost no negative sides can be found in this approach. It
is clear that the complexity of the protocol stack will increase as more communication
between modules must occur. This is potentially more error-prone than conventional
“isolated” layering as knowledge of different software modules must be possessed. This
“vertical” communication between protocols of different layers is not the only
combinatory approach. The active networking approach delivers “horizontal”
communication between different network protocols on the same layer. This is because,
in the philosophy of active networking it is believed that different protocols should be
used for different types of traffic having differing constraints This might well be a
advantageous approach as long as the routing logic remains manageable. We see great
security threats with reprogrammable routing logic as flexibility often implies the
possibility of abuse.

Proactive protocols for fixed networks do not work well for ad hoc networks. The
bandwidth is not sufficient for such protocols and especially distance vector protocols
would converge to slowly. Ad hoc distance vector and link state protocols have been
developed but it is not clear which class is better. Traffic requiring low initial delay
should use proactive protocols and on the other hand traffic requiring that as much of the
bandwidth as possible is available for data messages should use reactive protocols16.
Active networking could solve this dilemma. For instance, in active networking it is
possible to have a proactive backbone and let nodes connect to this backbone and find
routes reactively.

8.1.2 Connecting to the Internet

When connecting an ad hoc network to the Internet there are several things that have to
be sorted out. It is not enough to connect the mobile node to an intra-ad hoc network and
provide an address for that particular network if other nodes on the Internet should be
able to contact the node. Additionally, we assume here that the node can roam between
subnets. The mobile node can be addressed by any node on the Internet if there is another
fixed node (home agent) on the Internet that is constantly informed about the mobile
  Proactive protocols can be either a link state or distance vector type protocol. Reactive schemes cannot
be of link state type. Examples of reactive schemes are distance vector and source routing.

node’s whereabouts. It is also this fixed node that redirects the request to find the mobile
node. At the moment this is implemented with Mobile IP, but if textual IP addresses are
used, another lookup must also be made, namely at the DNS server in order to translate
the text address to numeral. As we mentioned in chapter 4 this could be simplified by
removing Mobile IP and letting the DNS server point to the right ad hoc network at all
time. This could for instance be done by letting the mobile node first be assigned an
address (through propagating DHCP advertisements) and then informing the dynamic
DNS about the network address change. This would remove the need for an dedicated
Mobile IP home agent and reduce the level of indirection to only one lookup.

Ad hoc trådlösa nätverk är datornätverk med temporär infrastruktur. De kan organisera
denna infrastruktur efter behov när två eller flera datorer befinner sig i samma
geografiska område. Datorerna som oftast är handhållna eller bärbara mobildatorer måste
kunna känna av varandra och organisera ett optimalt nätverk för stunden. Länkarna som
bygger upp infrastrukturen för dataöverföring mellan datorerna kan vara radiovågor eller
infrarött ljus. Förutom att upptäcka andra datorer måste nätverket även göra det möjligt
för datorer som inte är inom varandras radiovågors räckvidd att kunna kommunicera
indirekt. Detta uppnås genom att låta mellanliggande datorer vidarebefordra (eng.
forward) meddelanden mellan sådana datorer som inte kan kommunicera direkt. P.g.a. att
datorerna är mobila måste varje dator som deltar i framföring vara underrättad om hur
nätverkets infrastruktur (topologin) ser ut för tillfället. Detta sker med ett
ruttningsprotokoll (eng. routing protocol) som skickar s.k. styrmeddelanden (eng. control
messages) för att upptäcka topologin.

Varje dator, eller värd som man också brukar benämna dem, kan kommunicera direkt
med andra värdar som finns inom räckhåll för deras radiovågor. Dessa värdar kallas för
grannar. Traverseringen av en sådan länk kallas för ett ”hopp” på en rutt mellan två
värdar. Denna typ av vidarebefordring förutsätter att varje värd i ett ad hoc-nätverk också
fungerar som en router och är alltså beredd att framföra paket som är någon annans. En
del protokoll tillåter värdar med svaga batterier att delta selektivt i vidarebefordring.

1.1 Problembeskrivning

I ad hoc-nätverk är det ytterst viktigt att hålla meddelandekomplexiteten (antalet
kontrollmeddelanden) låg, inte bara för att spara bandbredd för användarnas
datameddelanden men också för att minska på risken att det sker kollisioner på
medieåtkomstnivå (se avsnitt 1.2). Detta skall ske på samma gång som man löser
ruttningsproblemet, d.v.s. hur man tillhandahåller rutter åt värdar. I denna pro gradu-
avhandling undersöks befintliga protokoll som alla löser dessa problem på olika sätt. Vårt
mål var att få en djup insikt i vad det betyder att specificera ett ad hoc nätverksprotokoll
och förutom litteraturstudien har vi utvecklat ett protokoll kallat ”Tree Routing Protocol”
(TRP, se kapitel 2).

Målet med ad hoc-nätverk är att tillhandahålla nätverksaccess där två eller flera
datoranvändare strövar. Denna text är ett sammandrag som behandlar mjukvara som gör
det möjligt för dylika ad hoc-nätverk att fungera.

1.2 Medieåtkomst

När man använder sig av radiosignaler för dataöverföring måste det ske på ett kontrollerat
sätt eftersom inte vilket frekvensband som helst kan användas, utan det måste delas av
värdar i ett nätverk. Problemet att lösa blir då – hur tillhandahålla turer för
datatransmission så att dessa inte kolliderar. I de flesta nätverk som kan indelas enligt
OSI-modellen använder ett medium åtkomstprotokoll (eng. Medium Access Control,
MAC17 protocol) för att avgöra hur sändningar skall skeduleras. MAC-protokoll kan vara
distribuerade eller centraliserade. Bluetooth t.ex. är centraliserat med hjälp av en
”mästare” (eng. master) som håller reda på slavars sändningsturer och utdelar dessa i tur
och ordning. IEEE 802.11 [IEEE99] är ett annat MAC-protokoll som använder sig av ett
distribuerat kontrollsystem då värdarna är inställda i ad hoc-läge. I 802.11 tävlar värdar
om sändningsturer och den som hinner först får skicka. Om två eller flera värdar skickar
på en gång kommer en på måfå vald värd att skicka först genom att båda ”lottar” ut en tid
de väntar innan de prövar på nytt.

1.3 Nätverksnivån

Som i klassiska, statiska nätverk hör ruttningsprotokoll i ad hoc-nätverk till OSI-
modellens tredje nivå, den s.k. nätverksnivån. Ett protokoll på denna nivå utför ruttning
(upptäcker topologin) och vidarebefordring. Typen av ruttningsprotokoll avgör hur stor
del av topologin som måste vara känd för var och av värdarna. Det finns två
huvudgrupper av ruttningsprotokoll i ad hoc-nätverk – dessa är proaktiva och reaktiva
protokoll. De proaktiva protokollen fungerar enligt samma princip som protokollen i
statiska nätverk – varje värd håller reda på rutter till varje annan värd hela tiden. Detta
betyder att det kommer att skickas en hel del onödiga styrmeddelanden om inte alla rutter
används. Detta har man försökt åtgärda i reaktiva protokoll där man endast upprätthåller
rutter till sådana värdar man aktivt skickar packet. Utdata av ruttningsfasen kan sedan
användas för att framföra paket. Protokoll kan även indelas enligt den klassiska
klassificeringen av ”distance vector” (DV) och ”link state” (LS) protokoll. Protokoll av
LS-typ kan inte vara reaktiva. Vi skall nu ta upp ett existerande protokoll. Det är ett DV,
reaktivt protokoll kallat ”Ad hoc On-Demand Distance Vector” (AODV).

1.3.1 Ad hoc on-demand distance vector protocol (AODV).

En värd (källa) i ett AODV-nätverk [Perkins+99] dränker hela nätverket med
styrmeddelanden kallade ”Route Requests” (RREQ) när källan inte känner till en rutt till
den värd den söker efter (destination). Dränkningen fungerar genom att källan sänder ett
RREQ åt sina grannar och därefter gör grannens grannar det samma o.s.v. Detta betyder
att RREQ-meddelandet kommer fram till destinationen såvida den finns i nätverket. Varje
mellanliggande värd som framför RREQ-meddelanden noterar vem som skickade den till
     MAC nivån är en under nivå av data link nivån som år den andra nivån i OSI modellen.

sig och får då en pekare ”bakåt” mot den värd som är nästa hopp mot källan, d.v.s. den
mellanliggande värd som kan föra ett meddelande mot källan. Detta behövs när svaret på
RREQen skall ges med en s.k. ”Route Reply” (RREP). När RREQen når fram till
destinationen eller en mellanliggande värd med tillräckligt ny rutt (nästa hopp) till
destination kan den värden svara med ett RREP och specificera att den kan användas som
nästa hopp till destinationen. Då en destination skickar ett svar på en RREQ med RREP
genererar den ett sekvensnummer som den lägger i en RREP. Därefter skickar den denna
RREP tillbaka till källan längs den rutt som sattes upp då RREQ traverserade mot
destinationen. Varje mellanliggande värd som får RREP att vidarebefordra noterar detta
sekvensnummer, vilket kommer att läggas i kommande RREQ. När sedan mellanliggande
värdar svarar på dessa RREQ-meddelanden måste sekvensnumret i deras ruttabell vara
åtminstone lika stort som det som finns i RREQ för att ruttens skall betraktas som
tillräckligt ny. Det kan ju hända att två meddelanden har traverserat två olika rutter och i
sådant fall får en mellanliggande värd duplikat. Dessa känns igen genom dränknings-ID
(ett sekvensnummer) och källans IP-adress. Värdar bör också ignorera meddelanden som
har traverserat längre rutter genom att kontrollera antalet hopp som paketet har traverserat
(anges i huvuddelen av paketet). På detta sätt kan meddelandekomplexiteten reduceras.

Ruttabellerna innehåller poster bestående av destination, nästa hopp mot destinationen
och längden (antalet hopp) till destinationen. Dessa rutter har också en ålder associerad
som säger när en rutt skall raderas p.g.a. den stora sannolikheten att denna rutt redan är
sönder (värden har flyttat utom radio räckhåll) p.g.a. mobilitet. Detta motverkar
utbredning av rutter som inte längre finns till. Varje gång en rutt används sätts dennes
ålder till noll.

För att säkerställa att alla grannar ännu faktiskt är grannar skickar värdar s.k. ”hello-
meddelanden” till sina grannar inom vissa intervall. Om ett hello-meddelande inte fås
efter vissa specificerade sekunder kommer en värd att deklarera en granne som f.d.
granne. I detta fall kan aktiva grannar informeras om detta med ett speciellt RREP-

1.3 Kommunikation mellan ändpunkter

Liksom ruttningsprotokoll, måste också transportprotokoll (OSI nivå 4) göras om för att
vara effektivare. TCP som används som Internets transportprotokoll, fungerar inte bra
omodifierat i ad hoc-nätverk. Detta beror på att TCP har en funktion som förebygger
trafikstockning, vilken försäkrar att sändaren inte sänder för mycket paket så att
mottagaren inte hinner processera dem. Detta märks när inga kvitteringsmeddelanden fås
som i sin tur gör att sändaren sänder sina paket långsammare. När en radiolänk bryts
kommer inte heller kvitteringsmeddelanden fram, vilket kommer att medföra att
sändarens takt görs långsammare även om en ny rutt är funnen. Detta kommer hindra
optimal användning av nätet.

Transportprotokoll associeras ofta med kommunikation mellan ändpunkter i statiska
nätverk, d.v.s. mellanliggande routrar har ingen transportnivå. I ad hoc-nätverk måste

denna modell ändras och låta mellanliggande routrar (vanliga värdar) delta i
transportprotokollet. T.ex. sker detta genom att skicka kvittering vid varje hopp (mellan
mellanliggande värdar) istället för att destinationen kvitterar källan för varje paket. På
detta sätt kan källor informeras explicit snabbare än om man låter en väntetid löpa ut hos

TRP är ett protokoll som utvecklades för denna pro gradu-avhandling i pedagogiskt syfte
för att förstå vad det betyder att utveckla ett optimerat ruttningsprotokoll. TRP har också
ett sätt att minimera meddelandekomplexiteten. Denna metod går ut på att delvis känna
till topologin (delvis proaktivt) och på så sätt göra intelligentare vidarebefordringsbeslut
för ”Route Query”-meddelandena (jfr. RREQ i AODV). Detta beslutsfattningssystem
baserar sig på att ett nätverk representerad av en graf också kan ses som ett träd om vissa
länkar (bågar) tas bort som figur 2–1 visar.

                          1                                                  1

                 2                   3
                                                                       2            3

                                         5                    4                         5

                          Grafvy                                           Trädvy

                                   Fig. 2–1: Olika vyer av nätverket

Ett träd uppkommer när en värd startar upp och märker att den inte har några grannar. Då
deklarerar den (roten av trädet) ett träd-ID som är det samma som dess ID. Värdar (barn)
som därefter kommer nära trädet ansluter sig till det, eller mera exakt till en annan värd
(föräldern) i trädet som har den kortaste rutten till roten. Varje värd som ansluter sig
kopierar detta trädID vilket senare kan behövas för att identifiera olika träd. Det är då
möjligt att värden har kontakt med andra värdar i trädet – dessa länkar kallas då
”extralänkar”. I figur 2-1 är de streckade linjerna extralänkar. Extralänkarna kopplas inte
helt bort utan de används vid vidarebefordring av datameddelanden. Varje värd som
kopplar sig till ett träd skickar ett uppdateringsmeddelande till föräldern och föräldern
adderar sig själv till meddelandet och skickar det till sin förälder. Detta ackumulerande
meddelande växer för varje hopp uppåt i trädet och när det kommer fram till roten
kommer den att känna till alla värdar i trädet. Dessutom kommer alla värdar att känna till
sina barn. I figur 2-1 betyder det att rot 1 känner till alla värdar och att t.ex. värd 2 känner
till värd 4. Det att värdar ansluter sig till föräldrar med korta rutter till roten betyder att de
kända rutterna är så korta som möjligt. För att känna till andra värdars distans från roten
skickas hello-meddelanden när en värds MAC-information indikerar en ändring (nya
grannar eller barn). Mottagna hello-meddelande jämförs och en värd ansluter sig till
grannen med minst hopp till roten. TRP är speciellt på det sättet att uppdaterings- och

hello-meddelanden endast skickas då en ändring i värdens information om sina grannar
(indikerat i MAC) eller barn (indikerat i uppdateringsmeddelandet från dess barn) sker.
För att minska på storleken på uppdateringsmeddelandet kan man skicka inkrementella
meddelanden som endast innehåller ändringen.

När två barnvärdar som inte hör till samma träd kommer i kontakt med varandra kan de
bilda en s.k. interlänk mellan de två träden. På detta sätt kan värdar i två eller flera olika
träd kommunicera med varandra. Om en av värdarna (eller båda) är rot så skall denna
inkludera sitt träd med det andra trädet, d.v.s. den ena roten blir ett barn av barnvärden i
det andra trädet. Detta är ett sätt att maximera det förstorade trädets rots vetskap om det
nya trädet. Hade det bildats en interlänk mellan träden så skulle de två rötterna endast
känt till sina egna träd. Figur 2–2 visar en interlänk mellan två olika träd.



                      2               3

                                                            6             7


                                 Fig. 2–2 En interlänk mellan två träd.

När en värds relativa hastighet är större än de andras kommer den att bryta länkar till sina
gamla grannar och förbinda sig till en ny beroende på informationen som fås i hello-

2.1 Ruttupptäckt

När en källvärd inte har en rutt till en destinationsvärd kommer den att skicka ett s.k.
”Route Query Message-meddelande” (RQM) till grannar som finns kopplade med
extralänkar, interlänkar eller förälderrelation. Dessutom skall RQM skickas till barn som
är subrötter för subträd med extralänkar, interlänkar eller innehåller destinationsvärden.
RQM-meddelandet skickas inte till sådana barn vars subträd är stängt. I figur 2-3 visar vi
vad vi menar med ett stängt subträd. Där är subträdet bestående av värdarna 8, 9 och 0
stängt, ty det har ingen extralänk eller interlänk. Om subträdet dessutom inte innehåller
den sökta värden så är det ingen nytta med att vidarebefordra RQM dit. Det är just detta
som är den bärande idén bakom TRP, d.v.s. att man kan minska
meddelandekomplexiteten genom att tillhandahålla värdar med så mycket information att
värdar kan göra intelligenta vidarebefordringsbeslut när man upptäcker rutter.




                        5            6           7           8

                                                         9          0
                         Rikting av okvitterad RQM

                         Riktning av kvitterad RQM
                                         Fig. 2–3

Vi tar som exempel nätverket i figur 2–3 och beskriver hur rutter upptäcks med TRP. Om
värd 5 vill hitta värd 4 så händer följande: Ett RQM skickas till 3:an som i sin tur skickar
det till 6:an för att den har en extralänk samt till 2:an som är dess förälder. Meddelandet
som skickades till 2:an kommer att komma fram till rot 1 som känner till en rutt till värd
4 och kan därför kvittera RQMet och skicka det till 5:an. Detta är möjligt för nästa hopps
pekare sätts upp på samma sätt som i AODV. När 6:an får samma RQM från 3:an
kommer den också att kunna kvittera ty 4:an är dess granne och känner därmed till rutten.
För varje hopp som ett RQM traverserar kommer en räknare att höjas med ett och
dessutom då en mellanliggande värd kvitterar ett RQM måste den addera den kvarstående
rutten till destinationen. Så värd nummer 3 kommer att få två kvitterade RQM tillbaka, en
med rutt av längden 4 och en med längden 2. I detta skede raderar värd 3 det meddelande
med längre rutt vilket minskar meddelandekomplexiteten. Antalet hopp som registreras i
meddelanden kommer att kunna användas som medel att förebygga meddelandecykler.
Om en värd registrerar ett RQM med en visst antal hopp traverserade och om den får
detta RQM tillbaka efter att det har traverserat en cykel så kommer RQMet att ha ett
större antal traverserade hopp. En värd som märker detta kan radera meddelandet.

Figur 2-3 är mycket simplifierad. Det är möjligt att lövnoder i trädet skulle ha stora
subträd som inte behöver dränkas med RQM-meddelanden och då skulle TRPs
inbesparing av meddelandekomplexiteten vara stor.

2.2 Framföring av datameddelanden

När ett RQM har traverserat fram och tillbaka mellan en källa och en upphittad
destination kan källan börja skicka datameddelanden som följer samma rutt av nästa
hopps pekare vilken nyss sattes upp av RQM-meddelandet. Eftersom RQMen inte kan gå
i cykler, kan inte heller datameddelanden göra det. Om en värd håller på att föra fram ett
datameddelande, men just då märker att rutten har bryts (nästa hopps värden har flyttat
utom radioräckhåll), så skall denna värd informera källan om detta. Källan skall då radera
den gamla rutten och upptäcka en ny rutt för destinationen. Detta gör den upptäckande
värden m.h.a. ett ”destinationen oåtkomlig”-meddelande som också får varje
mellanliggande värd på rutten att radera deras nästa hopp för denna destination.

Simulatorn som TRP-simuleringarna utfördes på är skriven av oss i
programmeringsspråket C. Detta gjordes för operativsystemet Linux och körningarna
gjordes på en dator med följande specifikation: processorn var en AMD Athlon med en
klockfrekvens på 1GHz och 256 MB RAM. Simulatorn har en nivå struktur som riktiga
protokoll. Vi antar att MAC nivån kan ange vilka är en värds grannar och endast det.
Nätverksnivån simuleras genom att ha olika processer med angivna UDP portar som de
lyssnar på. Portnummret är det samma som processens (värdens) ID nummer. Värdarna i
simulatorn kan alltså endast kommunicera genom UDP meddelanden vilket också gäller
verkliga ruttningsprotokoll. När simulationen startas väljer de 25 värdarna på måfå en
plats i ett 300mx300m stort koordinatsystem (Fig. 3-4). Därefter börjar de börjar de
mobilisera med en fart som är angiven för en körning. Riktningen väljs också på måfå
antingen i riktning med någondera axlarna eller diagonalt. Samma sker då en värd
kommer till gränsen av koordinatsystemet.

                     Fig. 3-4: 25 värdar på en 300x300 meters area .

De resultat vi väntar oss att få ur simulatorn är de följande: andelen mottagna
datameddelanden som kommer fram till destinationen, antalet RQM-meddelanden som
måste skickas för att upprätthålla rutter, latenstiden för upptäckning av rutter och antalet
framförda styrmeddelanden. Under de 30 sekunder som en körning omspänner, skickar
värdarna på måfå datameddelanden till olika värdar med frekvensen 1med./sekund. För
varje hastighet gjorde 10 körningar vilkas medeltal är visade i figurerna 3-5 till 3-7. I
figurerna finns även standardavvikelsen för körningarna.

3.1 Resultat

Resultaten som simulatorn indikerar är lovande. Figur 3-5 visar andelen mottagna
meddelanden av de skickade. När hastigheten ökas från 0 till 10 meter per sekund sjunker
andelen en aning tills 5 m/s är nås. Därefter avtar minskningen en aning tills 8 m/s nås.
Detta fenomen verkar finnas i de andra graferna också.

                        Andelen mottagna datameddelanden
               120 %

               100 %

                80 %

                60 %

                40 %

                20 %

                       0    1    2   3    4     5     6   7   8   9   10

                                      Hastighet m/s

                                         Fig. 3-5

                            Antalet RQM skickade per värd







                        0     1   2   3      4    5   6    7   8   9   10

                                      Hastighet, m/s

                                           Fig. 3-6

Grafen i figur 3-6 visar att mycket få RQM-meddelanden skickas även under höga
hastigheter. Tiden det tar att upptäcka rutter till destinationer i medeltal är uppvisad i
figur 3-7. Grafen verkar vara mera självständig från de andra med en större

                            Latenstid i ms för upptäckning av rutter









                        0     1   2   3      4    5   6    7   8   9   10

                                          Hastighet, m/s

                                           Fig. 3-7

Varje graf visar en försämring av resultaten från 0 - 5 m/s. Därefter blir resultaten bättre
ända tills 8 m/s är nås. Det är möjligt att hastigheten i det skedet är så hög att inte båda
RQMen misslyckas med att hitta sin destination, d.v.s. en ny rutt har bildats när det andra
RQMet försöker hitta sin destination. Latenstiden för att hitta rutter är kort, men ännu
kortare kunde man göra den med aktiv ruttföråldring på samma sätt som AODV.
Resultaten är inte direkt jämförbara med andra protokoll men de indikerar goda
egenskaper som kommer att kunna bli grunden för ett bra protokoll.


[Lei+97] Ad Hoc Networking with Mobile IP, Hue Lei and Charles E Perkins,
Proceedings of 2nd European Personal Mobile Communication Conference, 1997.

[Perkins+01] Ad Hoc Networks, Charles E Perkins, Addison-Wesley, 2001.

[Karn90] A new Channel Access Method for Packet Radio, P. Karn, ARRL/CRRL
Amateur Radio 9th Computer Networking Conference, Sept. 22 1990.

[Bakre+95] I-TCP: Indirect TCP for mobile hosts, A. Bakre and B. Badrinath, Proc. 15th
Intl. Conf. on Distributed Computing Systems (ICDCS), Vancouver, Canada, May 1995.

[Kim+01] TCP-BuS: Improving TCP Performance in Wireless Ad Hoc Networks,
Dongkyun Kim, C.-K. Toh, and Yanghee Choi, Journal of Communications and
Networks, vol3, no.2, June 2001.

[Stevens97] RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms, W. Stevens, 1997.

[Chandran+98] A Feedback Based Scheme For Improving TCP Performance In Ad-Hoc
Wireless Networks, Kartik Chandran, Sudarshan Raghunathan, S. Venkatesan, Ravi
Prakash, The 18th International Conference on Distributed Computing Systems,
Amsterdam, Netherlands, 1998.

[Toh02] Ad Hoc Wireless Mobile Wireless Networks, C-K Toh, Prentice Hall PTR,

[IEEE99] ANSI/IEEE Std 802.11, 1999 Edition.

[Bharghavan+94] MACAW: A Media Access Protocol for Wireless LAN's 1994,
Vaduvur Bharghavan, Alan Demers, Scott Shenker, Lixia Zhang, ACM SIGCOMM
Computer Communication Review Volume 24 Issue 4, October 1994.

[Talucci+97] MACA-BI (MACA by invitation) - A Receiver Oriented Access Protocol
for Wireless Multihop Networks, F. Talucci, M. Gerla, and L. Fratta, Proceedings of

[Singh+98] PAMAS: Power-Aware Multi-Access protocol with Signalling for Ad Hoc
Networks, S. Singh and C. S. Raghavendra. ACM Computer Communication Review,
July 1998.

[Deng+98] Dual Busy Tone Multiple Access (DBTMA): A New Medium Access Control
for Packet Radio Networks, J. Deng and Z. Haas, Florence, Italy, 1998.

[Bao+02] Hybrid Channel Access Scheduling in Ad Hoc Networks, Lichun Bao
J.J. Garcia-Luna-Aceves, Proceedings of the 10th IEEE International Conference on
Network Protocols, 2002.

[Tanenbaum03] Computer Networks Fourth Edition, Andrew S Tanenbaum, Prentice
Hall PTR, 2003.

[Lin+95] A Distributed Control Scheme in Multi-hop Packet Radio Networks for
Voice/Data Traffic Support, Chun-hung Richard Lin and Mario Gerla, Proceedings of
IEEE ICC, 1995.

[Hu93] Distributed Code Assignments for CDMA Packet Radio Networks, Limin Hu,
Member, IEEE/ACM Transactions on Networking, vol. 1, No. 6, December 1993.

[Ibáñez] Unicast Routing Protocols for Mobile Ad Hoc Networks (MANETs): Overview,
issues and perspectives, Guillermo Ibáñez, Telemática Universidad Carlos III de Madrid.

[Kim+02] Performance analysis of power-aware route selection protocols in mobile ad
hoc networks, Dongkyun Kim, J.J. Garcia-Luna-Aceves, Katia Obraczka, Juan-Carlos
Cano and Pietro Manzoni, Proceedings of the 5th ACM international workshop on
Modeling analysis and simulation of wireless and mobile systems, Atlanta USA, 2002.

[Perkins+99] Ad-hoc On-Demand Distance Vector Routing, Charles E. Perkins,
Elizabeth M. Royer, Proceedings of the 2nd IEEE Workshop on Mobile Computing
Systems and Applications, New Orleans, February 1999.

[Johnson+96] Dynamic Source Routing in Ad Hoc Wireless Networks, D.B. Johnson and
D.A. Maltz, Mobile Computing, chapter 5, pp.153-181, Kluwer Academic Publishers,

[Tschudin+00] Active Routing for Ad Hoc Networks, Christian Tschudin and Henrik
Lundgren, Uppsala University, Henrik Gulbrandsen, Ericsson Research, x IEEE
Communications, 2002.


To top