13.07.2015 Views

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Proactive QoS Rout<strong>in</strong>g <strong>in</strong> Ad Hoc Networks 63Besides the MPR selection method, a node also needs to change the “shortest hopspath” algorithm <strong>in</strong> its rout<strong>in</strong>g table computation so as to f<strong>in</strong>d the best bandwidth route.We use the “Extended BF” algorithm [6], which computes the best bandwidth pathsfrom a source to any reachable dest<strong>in</strong>ations with m<strong>in</strong>imum hop count (shortest-widestpath).With bandwidth constra<strong>in</strong>t as QoS metric, it is reasonable to view the “bandwidth”as available bandwidth. Most probably, the devices <strong>in</strong> the Ad-Hoc network will beconfigured with the same wireless card, which means that all nodes <strong>in</strong> the networkhave the same maximum bandwidth. So we are only <strong>in</strong>terested <strong>in</strong> how much of therema<strong>in</strong><strong>in</strong>g bandwidth is available for new traffic. However, <strong>in</strong> real networks, bandwidthcomputation is a complex issue. Many papers such as [9] discuss how to computebandwidth <strong>in</strong> Ad-Hoc networks. Here, we use a rather simple and straightforwardapproach: measur<strong>in</strong>g how much time a node monitors an idle channel and thusis available to transmit new messages over a l<strong>in</strong>k (node’s idle time), which is similarto the approach suggested <strong>in</strong> [1].3 QoS OLSR Implementation <strong>in</strong> OPNETThe Naval Research Laboratory (NRL) of the United States Department of Defensedeveloped the orig<strong>in</strong>al OLSR model <strong>in</strong> OPNET. To implement the QoS versions ofthe OLSR protocol, besides chang<strong>in</strong>g the MPR selection mechanism and the rout<strong>in</strong>gtable calculation, the follow<strong>in</strong>g revisions are made to develop the QoS OLSR model.QoS OLSR uses the media idle time to reflect the available bandwidth over a l<strong>in</strong>k.Modify<strong>in</strong>g the standard OPNET Wireless LAN model achieves this task. EachOPNET OLSR node connects to the wireless media. The OPNET Wireless LANsimulation model <strong>in</strong>cludes a transmitter, and a receiver. If a node is send<strong>in</strong>g packets,its transmitter becomes busy. If there are other nodes beg<strong>in</strong>n<strong>in</strong>g transmission with<strong>in</strong>the <strong>in</strong>terference range of the current node, its receiver senses the busy media andsends a media busy signal. As the OPNET Wireless LAN model already def<strong>in</strong>es functionalitiesto capture changes of the media, the media idle time calculation, us<strong>in</strong>g aslid<strong>in</strong>g w<strong>in</strong>dow over the past 5 seconds, is straightforward.Also, the QoS OLSR versions need to know the available bandwidth on theneighbor l<strong>in</strong>k to select MPRs, and the available bandwidth of the far-away l<strong>in</strong>ks tocompute the rout<strong>in</strong>g table. As idle time should be used to calculate the availablebandwidth on the l<strong>in</strong>ks, we revise the format of OLSR Hello and TC messages to<strong>in</strong>clude the idle time.a. Hello message: <strong>in</strong> addition to the orig<strong>in</strong>al <strong>in</strong>formation such as neighbor addressand neighbor l<strong>in</strong>k type, a node also <strong>in</strong>cludes its own idle time <strong>in</strong> the Hello messages.Upon receiv<strong>in</strong>g a Hello message from its neighbor, a node reads the neighbor idletime, and selects MPRs us<strong>in</strong>g the QoS MPR selection algorithm.b. TC message: the TC message orig<strong>in</strong>ator not only puts its own idle time <strong>in</strong> TCmessages, but also piggybacks its MPR selectors’ idle times, which are obta<strong>in</strong>ed fromthe Hello messages. When a node receives TC messages, it knows the idle time <strong>in</strong>formationof both the TC message orig<strong>in</strong>ator and the MPR selectors, thus gets <strong>in</strong>formationabout the l<strong>in</strong>ks and the l<strong>in</strong>k bandwidth between the TC message orig<strong>in</strong>ator and

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!