[Ns-developers] 802.11 beacon implementation
Ali Hamidian
ali.hamidian at telecom.lth.se
Thu Mar 8 15:22:04 PST 2007
Hi,
Ramon Aguero skrev:
> Hi,
>
> although I understand your point, I have to say that I think it's
> better to assess first the functionality over infrastructure networks
> (as a functional issue).
>
> Based on my personal experience, the beacon procedure in ad-hoc
> networks does not have a severe impact on the performance, and we may
> have an issue with multi-hop networks, since AFAIK, current 802.11
> distributed beacon generation does not support mulit-hop networks,
> e.g. in order to be part of the same BSSID, all nodes should be within
> the same coverage area.
Hmmm... recently I was thinking about the same thing, that is, beacons
in multi-hop ad hoc networks based on 802.11... So how does it work in
the real world?
Ali
>
> Just my two cents,
> Ramón
>
> At 02:45 08/03/2007, Farrag, Osama wrote:
>
>
>> I was advocating for including support for beacons in adhoc mode, and
>> went on trying to show that without it we have important drawbacks in
>> accuracy of results when 802_11 adhoc MAC is used due to bandwidth
>> consumed by beacons and beacon induced collisions.
>>
>> 1) I did not use version 2.30 yet, indeed I am still working with 2.29.
>> So it is good that this problem has been taking care of already.
>>
>> Good luck, and give beacons in adhoc mode a thought while you are at it
>> :)
>>
>> cheers
>> Osama Farrag
>>
>> -----Original Message-----
>> From: Ilango Purushothaman [mailto:ilangop at u.washington.edu]
>> Sent: Wednesday, March 07, 2007 8:33 PM
>> To: Farrag, Osama
>> Cc: ns-developers; Tom Henderson; sroy at u.washington.edu
>> Subject: RE: [Ns-developers] 802.11 beacon implementation
>>
>>
>> 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
>> >
>> >
>
>
>
>
More information about the Ns-developers
mailing list