[ns] access dei80211mr rate adapter rate
I have an adhoc network, which I'm using dei80211mr-1.1.1 (with activating the included rate adaptation on each node) to simulate 802.11g with rate adaptation. Is there a way to determine the current rate being used (call RateAdapter::getCurrMode() ) from dsragent.cc? I'm working with a modified version of DSR known as FRESH that uses a table of contact times on each node as a metric. A node looking for a route will broadcast a request to it's neighbors asking when they last saw the destination, and each neighbor will respond to the source of the broadcast. My question is, is the rate adapter sophisticated enough that each response will be sent at a rate appropriate for the communication conditions between the particular responding neighbor and the source? Secondarily is there a way to determine the rate each particular response was sent at, from within dsragent.cc? thank you for your time, Ryan
Re: [ns] access dei80211mr rate adapter rate
ryan m wrote: > I have an adhoc network, which I'm using dei80211mr-1.1.1 (with > activating the included rate adaptation on each node) to simulate > 802.11g with rate adaptation. Is there a way to determine the current > rate being used (call RateAdapter::getCurrMode() ) from dsragent.cc? That's cross-layer information exchange. Unfortunately there is no standard way of doing it in ns2. You need to develop an ad-hoc* solution, such as extending dsragent and allowing it to have a pointer to the rateadapter instance so that it can call its methods. * here I mean "ad-hoc" in the sense of "designed explicitly for this particular case" > > I'm working with a modified version of DSR known as FRESH that uses a > table of contact times on each node as a metric. A node looking for a > route will broadcast a request to it's neighbors asking when they last > saw the destination, and each neighbor will respond to the source of > the broadcast. My question is, is the rate adapter sophisticated > enough that each response will be sent at a rate appropriate for the > communication conditions between the particular responding neighbor > and the source? Secondarily is there a way to determine the rate each > particular response was sent at, from within dsragent.cc? RateAdapter itself defines only an API and provides some convenience methods/variables, however it implements no actual rate adaptation scheme. So the answer is: it depends on the actual rate adapter you're using. Each of the classes inheriting from RateAdapter implements a different rate adaptation scheme. The two distributed with dei80211mr are ARF and SNR. Both will work in ad-hoc mode, however with some caveats: 1) the ARF implementation we provide uses a single set of counters for all tx successful / failed events, so the behaviour in ad-hoc mode is not reasonable if the same STA sends often packets to different destinations, while it is more reasonable if the destination remains the same for a number of consecutive transmissions. 2) the SNR implementation records for all nodes the received SRN of the last received transmission, and the rate is chosen per-destination using that SNR value. So this scheme should work fine in ad-hoc mode, of course the SNR information for a given node will be only as recent as the last received packet from that node. If you have particular needs you can of course implement your own rate adaptation scheme by inheriting from the RateAdapter class. Nicola > > thank you for your time, > Ryan >
Re: [ns] access dei80211mr rate adapter rate
In case anyone is ever interested in doing this each packet has the rate it was sent at stored in the multirate header, which does persist at least as far ast the routing layer. So by adding the dei80211mr-1.1.1/src and dei8021.1.1/src/adt to the include directors in the ns makefile as well as adding the library to the list of libraries you can link against, you can include mac-802_11mr.h then get to the mode a packet was sent at by: MultiRateHdr *mrh = HDR_MULTIRATE(p.pkt); mrh->mode(); which gives you a PHYMODE which is an enum, and not the most useful, so I made MR_PHY_MIB::getRate static in the mac-802_11mr.h file, then used it as so: double rate=MR_PHY_MIB::getRate(mrh->mode()); now rate is the rate the packet was sent at in bits/second, certainly a more useful number :-D hope this helps someone looking through the archives, Ryan On Dec 13, 2007 11:01 AM, Nicola Baldo <[EMAIL PROTECTED]> wrote: > ryan m wrote: > > I have an adhoc network, which I'm using dei80211mr-1.1.1 (with > > activating the included rate adaptation on each node) to simulate > > 802.11g with rate adaptation. Is there a way to determine the current > > rate being used (call RateAdapter::getCurrMode() ) from dsragent.cc? > > That's cross-layer information exchange. Unfortunately there is no > standard way of doing it in ns2. You need to develop an ad-hoc* > solution, such as extending dsragent and allowing it to have a pointer > to the rateadapter instance so that it can call its methods. > > * here I mean "ad-hoc" in the sense of "designed explicitly for this > particular case" > > > > > I'm working with a modified version of DSR known as FRESH that uses a > > table of contact times on each node as a metric. A node looking for a > > route will broadcast a request to it's neighbors asking when they last > > saw the destination, and each neighbor will respond to the source of > > the broadcast. My question is, is the rate adapter sophisticated > > enough that each response will be sent at a rate appropriate for the > > communication conditions between the particular responding neighbor > > and the source? Secondarily is there a way to determine the rate each > > particular response was sent at, from within dsragent.cc? > > RateAdapter itself defines only an API and provides some convenience > methods/variables, however it implements no actual rate adaptation > scheme. So the answer is: it depends on the actual rate adapter you're > using. > > Each of the classes inheriting from RateAdapter implements a different > rate adaptation scheme. The two distributed with dei80211mr are ARF and > SNR. Both will work in ad-hoc mode, however with some caveats: > > 1) the ARF implementation we provide uses a single set of counters for > all tx successful / failed events, so the behaviour in ad-hoc mode is > not reasonable if the same STA sends often packets to different > destinations, while it is more reasonable if the destination remains the > same for a number of consecutive transmissions. > > 2) the SNR implementation records for all nodes the received SRN of the > last received transmission, and the rate is chosen per-destination using > that SNR value. So this scheme should work fine in ad-hoc mode, of > course the SNR information for a given node will be only as recent as > the last received packet from that node. > > If you have particular needs you can of course implement your own rate > adaptation scheme by inheriting from the RateAdapter class. > > > Nicola > > > > > > > > > > > > thank you for your time, > > Ryan > > > >