[Ns-developers] 802.11 beacon implementation

[Ilango Purushothaman]

Hi Osama,

Thank you for your feedback on the various issues.


1) I am not sure if I understand your reply about beacons implementation correctly.

Right now, I am concentrating on Infrastructure mode simulation. If you have looked at the and the modified files and the section in my report where I have described the beacons implementation, you will note that was for DCF mode *only*, albeit, in Infrastructure mode (In the sense, Only the AP can send beacons.) I have not implemented beacons for ad-hoc mode, so far. 
You have raised the serious issue of hidden nodes though.

2) Reg. direct access denial, bugFix_timer just prevents the Defer timer from being used for backoff (So it avoids the problem of pausing the defertimer when the medium gets busy). But still, in 802.11 ns2, a node, which finds the channel idle and still finds the channel idle after DIFS, cannot grab the channel. It is forced to go into backoff.

Reg. tx_resume(), bugFix_timer is included in the tx_resume function (in ns-2.30). So, backoff timer will only be used in tx_resume() too. Maybe, you are using a older version ns-2.29?

3) Changing the cw size to 8,16,32.. etc is the best solution, indeed. Thanks for the suggestion. I was thinking of doing that.

I am implementing infrastructure mode now. I intend to fix the other issues later. Please do give me your suggestions about the my beacon report and test my implementation using the files that I have uploaded.

http://ee.washington.edu/research/funlab/802_11/report80211issues.pdf
http://ee.washington.edu/research/funlab/802_11/802_11_beacon.tar.gz

Your suggestions were certainly helpful. Keep sending them :)

Thanks,
Ilango




On Wed, 7 Mar 2007, Farrag, Osama wrote:

> Ilango;
>
> I am glad that there is some one taking the time to improve 802.11 for
> ns. I would recommend/hope that support for Beacon generation in DCF
> mode gets added as well. Currently as you know it is not supported.
> Beacons obviously will consume channel capacity and will impact
> performance of many protocols that run on top of any MANET that use
> 802.11 MAC. Also, beacons generated by hidden nodes could cause
> collisions at nearby stations that could be receiving data frames from a
> transmitting station far from the source node from station that
> generating beacon. So improving MAC layer model will provide more
> accuracy in results of higher layer protocols that could be sensitive to
> link throughput or reliability. So it is important in opinion.
>
> Regarding the issues sections, you pointed out few important issues.
>
> With respect to the Direct access denial issue:
>
> I think that the use of mhDefer_ timer for purpose of tracking when the
> medium is idle is problematic. So, using mhBackoff_ as recommended
> bellow is the way to go.
>
> if(mhBackoff_.busy() == 0) {
> 	if(is_idle()) {
> 		if (mhDefer_.busy() == 0) {
> 			/*
> 			* If we are already deferring, there is
> 			* no need to reset the Defer timer.
> 			*/
> 			if (bugFix_timer_) {
> 				mhBackoff_.start(cw_, is_idle(),
> 				phymib_.getDIFS());
> 			}
> 			else {
> 				rTime = (Random::random() % cw_)
> 				* (phymib_.getSlotTime());
> 				mhDefer_.start(phymib_.getDIFS() +
> 				rTime);
> 			}
> }
>
>
> However, there is still another area of code that needs to be fixed to
> address this; basically in tx_resume method when the code checks and
> finds pktRTS_ or pktTx_ not nil it uses mhDefer_ to wait for DIFS plus
> random backoff period; unfortunately 802_11 logic in NS never stops and
> restarts mhDefer_ when the medium becomes busy. So in theory, it is
> possible when data rate is high and if the random backoff period happens
> to towards the size of current cw_ that the medium could become busy and
> in fact the node receive a broadcast message, or worst yet unicast RTS
> message while mhDefer_ is busy which will cause a problem because CTS or
> ACK transmission attempt will cause double use of mhDefer_. mhDefer_
> should be used for SIFS only. So Basically, I recommend extending
> bugFix_timer to the two other locations in tx_resume where mhDefer_ is
> started with DIFS + random backoff durations to use mhBackoff_ instead.
>
>
> In Regard to the random Backoff observation: an easier fix is to change
> the values of contention windows to be 8, 16, 32, 64, 128, 256 instead
> of 7, 15, 31, etc. this should take of the mod problem that you pointed
> out. Just a suggestion to avoid looking for all areas were this mod
> operation is used.
>
> Finally I have a question regarding the capture issue, your document
> identified the current code, but did not elaborate on how you recommend
> fixing it. I agree with you that it should be possible to capture
> either.
>
>
> Hope my 2 cents are useful, Cheers
> Osama Farrag
>
>
> -----Original Message-----
> From: ns-developers-bounces at ISI.EDU
> [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Tom Henderson
> Sent: Wednesday, March 07, 2007 12:58 AM
> To: Ilango Purushothaman
> Cc: ns-developers; sroy at u.washington.edu
> Subject: Re: [Ns-developers] 802.11 beacon implementation
>
> Ilango Purushothaman wrote:
>> Hi,
>>   I have implemented beacon transmission and reception for 802.11 in
>> ns2.30.
>> The modified files can be downloaded from
>> http://ee.washington.edu/research/funlab/802_11/802_11_beacon.tar.gz
>> I have also attached a sample tcl file, which creates a basic
>> infrastructure network.
>>
>> Right now, beacon frames contain only address info and bssid.
> Timestamp,
>> supported data rates will be included in the next stage of my
>> infrastructure mode implementation. I am currently in the process of
>> implementing Passive scanning with Association request/response
> frames.
>> I will be ready with that code within two weeks.
>>
>> I have found some small issues while implementing beacons, which are
>> desribed in the report, along with an overview of the beacon
>> implementation.
>> http://ee.washington.edu/research/funlab/802_11/report80211issues.pdf
>>
>> Please go through the report and test my beacon implementation. I will
>
>> be glad to hear your feedback, about possible bugs in my code and
>> improvements, about the issues desribed in the report.
>>
>> Thank you,
>> Ilango Purushothaman
>>
>>
>
> I'd like to solicit some feedback on this work in the coming weeks, on
> this list.  We recently voted to add Ilango to the list of ns-2
> committers.  I'll work with him to prepare patches, documentation, and
> validation/example scripts as he continues with this work.
>
> I've started a tracker issue also for posting patches and comments
> against them, in the future:
> <<http://sourceforge.net/tracker/index.php?func=detail&aid=1675475&group
> _id=149743&atid=775394>>
> We'll also be revisiting the other 802.11 items in the tracker.
>
> Thanks,
> Tom
>
>