AD HOC NETWORK PROTOCOLS

Case Study: Tree Routing Protocol

Robert Löfman

Master’s ThesisSupervisor: Kaisa SereDepartment of Computer ScienceÅbo Akademi UniversityTurku, September 2003

Abstract

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.

i

Contents

1 INTRODUCTION............................................................................................................11.1 Ad Hoc Networks......................................................................................................11.2 Security......................................................................................................................21.3 Power Consumption...................................................................................................31.4 Applications for Ad Hoc Networks...........................................................................41.5 Problem Description and Overview of Our Work.....................................................5

2 WIRELESS MEDIA ACCESS CONTROL (MAC)........................................................62.1 The Shared Medium Problem....................................................................................72.2 MAC Protocols for Ad Hoc Networks......................................................................8

2.2.1 CSMA / CA........................................................................................................92.2.2 MACA................................................................................................................92.2.3 MACAW...........................................................................................................102.2.4 MACA-BI.........................................................................................................112.2.5 PAMAS.............................................................................................................122.2.6 DBTMA............................................................................................................132.2.7 MARCH............................................................................................................132.2.8 HAMA..............................................................................................................142.2.9 IEEE 802.11b....................................................................................................152.2.10 Bluetooth.........................................................................................................17

2.3 Discussion................................................................................................................18

3 AD HOC ROUTING PROTOCOLS..............................................................................213.1 The Routing Problem...............................................................................................213.2 Proactive and Reactive Protocols............................................................................223.3 Classification of Ad Hoc Routing Protocols............................................................233.4 Ad hoc On-Demand Distance Vector (AODV).......................................................24

3.4.1 Route Discovery...............................................................................................253.4.2 Path Maintenance..............................................................................................26

3.5 The Dynamic Source Routing (DSR) protocol........................................................273.5.1 Route discovery process...................................................................................283.5.2 Route Maintenance...........................................................................................283.5.3 Reflecting Shorter Routes.................................................................................29

3.6 Optimized Link State Routing.................................................................................293.7 Discussion................................................................................................................31

4 TCP FOR WIRELESS NETWORKS.............................................................................32

ii

4.1 Mobile IP.................................................................................................................324.2 Connecting to the Internet – TCP-I..........................................................................334.3 TCP within the Ad Hoc Network – TCP BuS.........................................................33

4.3.1 Domain Name Service......................................................................................364.4 Discussion................................................................................................................37

5 CASE STUDY, TREE ROUTING PROTOCOL...........................................................385.1 Definitions...............................................................................................................385.2 Introduction to TRP.................................................................................................395.3 Tree Construction - Routing....................................................................................405.4 Forwarding...............................................................................................................45

5.4.1 Forwarding of RQMs........................................................................................455.4.2 Preventing Loops..............................................................................................475.4.3 Forwarding of Data Messages..........................................................................51

6 PROOFS.........................................................................................................................52

7 SIMULATION................................................................................................................557.1 A Technical Description of the Protocol Simulator.................................................55

7.1.1 The Virtual MAC Layer...................................................................................567.1.2 The Network Layer...........................................................................................56

7.2 Simulation Settings..................................................................................................577.3 Results......................................................................................................................60

8 CONCLUSIONS............................................................................................................648.1 Summary..................................................................................................................64

8.1.1 Scalability.........................................................................................................648.1.2 Connecting to the Internet.................................................................................65

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

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

iii

List of Figures

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

iv

1 INTRODUCTION

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)

1 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.2 The MAC layer is a sub layer of the data link layer, which is the second layer in the OSI model.

1

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 networks.

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

2

[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 authenticated.

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 hardware4

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.

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

3

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 energy. 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

5 Defense Advanced Research Projects Agency

4

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.

5

2 WIRELESS MEDIA ACCESS CONTROL (MAC)

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.

6 The transmission technique is specified at the physical layer.

6

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.

Fig. 2-2: Hidden Terminal.

Radio range

B CA

7

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.

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 (BEB).

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.

B CA

8

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

9

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 up.

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

10

(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 DS.

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.

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

B CA D

11

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).

12

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 BT t (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).

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

3. DATA

4.CTS2

5.DATAB CA 2.CTS

1.RTS

13

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

14

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.

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).

7 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.

6 5

4 3 2

1

2 1

B

C E

FA

D

HG

15

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.

16

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 625sec 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 listener’s address, class and clock offset. The device class identifies the type of device in 8 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.

9 Bluetooth devices are identified with a 48bit MAC address.

Shortened

Trans.SIFS, PIFS, DIFSPolling (if BS)

1.the BS gains access with PIFS

2.the BS gains access as in 1.

Super frame 2.Super frame 1.

Sync. access Async. access

Polling

17

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

18

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 protocol.

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.

19

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 reception

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.

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 2-8.

MAC-protocols

HybridContention based(Distributed, asynchronous)

Conflict free(Synchronized)

ReceiverInitiated

SenderInitiated

Centralized Distributed

20

3 AD HOC ROUTING PROTOCOLS

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 this information, a shortest path algorithm can be run, which calculates the shortest path

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

21

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 bandwidth13 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 trade-off.

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

22

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 [Ibáñez].

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 complexity.

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.

Fig. 3-9: 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

Request Zone Expected Zone

23

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.

24

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:

25

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.

Fig. 3-10: 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

RREP 5

RREP 5 RREP 5

1

3

42

5

26

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.

27

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

28

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.

Fig. 3-11: 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 expunged.

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 routes might not be needed. The authors of OLSR have taken this into account and

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

Packet 1Source yx z

29

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-12: 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 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,

15 This picture is part of a demonstration found at the OLSR homepage http://menetou.inria.fr/olsr/mpr-flooding.html

30

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.

31

4 TCP FOR WIRELESS NETWORKS

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.

32

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

33

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.

Fig. 4-13: 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 (cwindadvertised 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.

Fig. 4-14: 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

FP

2.Repair

1.RFN

3.RRN

1

2

4

3

5

6

cwind Acknowledged segment1 12 2,3

4 4,5,6,78 8,9,10,11,12,13,14,15

34

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:

35

ERDN_GEN_SEQ=15,ERDN_RCV_SEQ=20,

LAST_ACK=10

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.

36

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.

37

5 CASE STUDY, TREE ROUTING PROTOCOL

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 vertex.

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

38

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 changes.

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.

39

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.

Fig. 5-15: 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

1

2 3

54

1

2 3

54

Graph view Tree view

40

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.

Fig. 5-16: 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.

1

2

1

2 3

1

2 3

4

41

Fig. 5-17: 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.

Fig. 5-18: 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

5

6 7

1

2 3

4Interlink

1

2 3

4 5 6

1

2 3

4

5

6

42

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.

Fig. 5-19: 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.

1

2 3

4 5 6

1

2

3

4

5 6

43

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.

Fig. 5-20: 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

1

2 3

4 5

1

2

3

4 5

2

3

4

5

44

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

45

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.

Fig. 5-21: 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.

46

Fig. 5-22: 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

1

2

34

5 6 7 8

Direction of the unacknowledged RQMDirection of the acknowledged RQM

47

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.

Fig. 5-23: 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

msg B at timeT+ro_time+delayB

1

msg A at time T

msg A at timeT+delayA

msg B at timeT+ro_time

network

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

msg A deleted at time T+delayA+st_time

2

48

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).

Fig. 5-24: Incorrect storage time.

1 4

msg A at time T=0

msg B at time0+15=15

msg A at time0+1+1+1+1=4

msg A deleted at time0+1+1+1+1+15=19

msg B received at time0+15+1+1+1=18

When receiving B before A is deleted causes B to be wrongly dropped.

Message A and B have the same ID number. Msg A is delayed at node 2 but B is not.ro_time=st_time=net_delay=15

2 3

6 5

msg A at time 0+1buffered 1TU

msg B at time0+15+1=16

msg A at time 0+1+1+1=3

msg B at time0+15+1+1=17

49

Fig. 5-25: 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.ELSE

add one to hops_traversed.

forward the RQM to appropriate neighbors.ELSE

discard r.

1 4

msg A at time T=0

msg B at time0+30=30

2 3

6 5

msg A at time 0+1buffered 1TU

msg B at time0+30+1=31

msg A at time 0+1+1+1=3

msg B at time0+30+1+1=32

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

ro_time=30st_time=net_delay=15

msg A at time0+1+1+1+1=4

msg A deleted at time0+1+1+1+1+15=19 (30 in worst case, if some other route than 1-2-3-4)

msg B received at time0+30+1+1+1=33

A is deleted before B arrives, this is OK even if msg A would have been delayed for the max time 15

50

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.

51

6 PROOFS

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.

52

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 andc(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 tVDE and eVDE (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 tree.

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).

53

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 4Node 4: - add edges [4,2], [4,3], [4,5]; nodes 2, 3, 5 Node 2: - 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)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

Fig. 6-26: 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.

1

2 3

54

6 7

54

7 SIMULATION

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 RAM.

55

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 these.

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.

56

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

57

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-27: 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

58

Fig. 7-28: 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-29: 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

59

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.

60

Avg. delivery rate of data messages

0 %

20 %

40 %

60 %

80 %

100 %

120 %

0 1 2 3 4 5 6 7 8 9 10

Speed m/s

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

Fig. 7-31: 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 occurs.

Avg. RQM rate per node

0

2

4

6

8

10

12

0 1 2 3 4 5 6 7 8 9 10

Speed, m/s

61

Fig. 7-32: Route discovery delay.

Fig. 7-33: 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

Avg. route discovery delay per node

0

10

20

30

40

50

60

70

80

0 1 2 3 4 5 6 7 8 9 10

Speed, m/s

Total amount of relayed control messages

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

0 1 2 3 4 5 6 7 8 9 10

Speed, m/s

62

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.

63

8 CONCLUSIONS

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.

64

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

16 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.

65

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.

66

1 INTRODUKTION

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.

67

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

17 MAC nivån är en under nivå av data link nivån som år den andra nivån i OSI modellen.

68

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-meddelande.

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

69

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 källan.

70

2 TREE ROUTING PROTOCOL (TRP)

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.

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

1

2 3

54

1

2 3

54

Grafvy Trädvy

71

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.

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-meddelanden.

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

1

2 3

4Interlänk

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

72

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.

1

2

34

5 6 7 8

Rikting av okvitterad RQM

Riktning av kvitterad RQM

Fig. 2––3

9 00

73

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.

74

3 SIMULERING

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.

75

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å.

Fig. 3-5

Andelen mottagna datameddelanden

0 %

20 %

40 %

60 %

80 %

100 %

120 %

0 1 2 3 4 5 6 7 8 9 10

Hastighet m/s

76

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 standardavvikelse.

Fig. 3-7

Antalet RQM skickade per värd

0

2

4

6

8

10

12

0 1 2 3 4 5 6 7 8 9 10

Hastighet, m/s

Latenstid i ms för upptäckning av rutter

0

10

20

30

40

50

60

70

80

0 1 2 3 4 5 6 7 8 9 10

Hastighet, m/s

77

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.

78

References

[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, 2002.

[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 IEEE PIMRC, 1997.

[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.

79

[Bao+02] Hybrid Channel Access Scheduling in Ad Hoc Networks, Lichun BaoJ.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, 1996.

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

80