[ns] access dei80211mr rate adapter rate

[Nicola Baldo]

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
>