[ns] Another CSThresh Question, protocol violation

Saikat Ray raysaikat at lycos.com
Wed Jan 28 06:08:38 PST 2004 

I did not say that the NS implementation of carrier sensing is good! The right way is to keep a status variable per node that indicates the channel status at that node. It is very inconvenient to mix physical carrier sensing and NAV. However, the current implementation does avoid packet collisions, which was the topic of this post.

By the way, we were discussing about the deferral of the node *during* the packet transmission time. EIFS is set *after* the packet transmission is over.

Also there are some subtle issues in the scenario you are depicting. Since the carrier sensing is positive, some node is transmitting nearby. Then another packet starts arriving at the node. Therefore, the issue is whether this new packet, that starts in the midst of another transmission, can "capture" the node. NS implementation assumes that the new packet will not be able to capture the channel, even if the power of the new packet is more than CPthreshold. One argument favouring this implementation is the following: the node will try to lock its PLL to decode the packet whose power is below RxThreshold, so the it will not lock its carrier to the new packet (or read garbage even if it does so). However, one argument against it is the following (:))): If the old packet came with very low power, the PLCP header will not be decoded, and the node will not try to decode the packet further, and thus can lock on to the new packet.

The problem is that NS does not implement a separate PLCP part of the packet (so that one can simulate a good PLCP, but a bad packet, etc). So, it is difficult to take a stand for any of the two arguments. In effect, NS assumes that if the the packet power is above CSThresold, then the PLCP header will be decoded without error (so argument 1 is valid).

----------- Original Message ---------

DATE: Wed, 28 Jan 2004 09:31:13
From: Ahmad Al_Hanbali <Ahmad.Al_Hanbali at sophia.inria.fr>
To: raysaikat at lycos.com
Cc: "Rahul R. Shetty" <rshetty at seas.upenn.edu>, ns-users at ISI.EDU

>
>Hi, 
>
>Saikat Ray wrote:
>> 
>> If packet power is greater than CSthrehold, but less than RxThreshold, then the packet is passed to the higher layer indicating that there is error. However, the higher layer advances nav for the packet duration before discarding an erroneous packet. So, this packet (with power less than RxThreshold but greater than CSThreshold) will make the receiving defer. This is the way NS implements carrier sensing. So, clearly CSthreshold has effects.
>
>What you mention here is true, But imagine this scenario, after
>advancing the nav for the eifs duration, i receive a RTS according 
>to the CTS procedure of the protocol specification i have to reply by a
>CTS if i determine the medium idle 'virtually' only ( virtually means
>nav). But as the nav will indicate busy state i will not respond by a
>CTS. So setting the nav to eifs duration may generates a protocol
>violation. what i suggest that we have to wait an eifs but another
>mechanism than setting the nav.
> 
>
>> 
>> My suggestion was to check the range with two node topology with the set of (CS,Rx) threshold values for which you expect to get 40m range. This check would eliminate the possibility that the program you are using to map range (in m) to threshold (in watt) was not used properly.
>
>
>> 
>> >
>> >Well, I just created a simple two node topology and used the default
>> >values to check the distance as suggested by you.
>> >
>> >Anyway I just took a look at /mac/wireless-phy.cc where CSTHresh is used. In this code, the
>> >power level Pr is compared to CSThresh, if Pr < CSThresh, no
>> >packets are received. Even if Pr > CSThresh but Pr < RXThresh, the packets are
>> >considered errored and dropped. So I guess thats the only purpose CSTHresh
>> >is serving, it basically serves no purpose ( am I right ). There is no
>> >carrier sense happening for higher CS range, so RXthresh determines the
>> >carrier sense range.
>> >
>> >On Tue, 27 Jan 2004, Saikat Ray wrote:
>> >
>> >> It is not possible in a real network to have a smaller CS range! This is tautological, since if CS threshold is smaller, what you are claiming is that you can decode the packet but cannot sense it!!!!
>> >>
>> >> You initially said that nodes are 40m apart, but now you are saying that the minimum distance is 725m. If all the nodes are already within the transmit range, then there would not be any difference depending on the CS value.
>> >>
>> >> Next time if you attach a script of your scenario, as small as possible, I can take a look at it.
>> >>
>> >> ----------- Original Message ---------
>> >>
>> >>
>> >> >
>> >> >Minimum distance is 725m i.e RxThresh= 3.65e-10 and CSThresh=1.559e-11
>> >> >(all default value), beyond which no packets are recevied.
>> >> >For nodes less than 725 m apart, when CSThresh <= RXthresh
>> >> >(i.e cs range is more), packets are received without
>> >> >any drops. When CSthresh > RXthresh (cs range low) all packets are dropped
>> >> >which makes sense.
>> >> >Well so again it comes back to my question, in my previous topology why
>> >> >are the rsults similar i.e why are there same number of collisions when
>> >> >the CSThresh < RXThresh as compared to CSThresh=RXThresh
>> >> >
>> >> >On Tue, 27 Jan 2004, Saikat Ray wrote:
>> >> >
>> >> >>
>> >> >> Typically NS scripts use Propagation/TwoRayGround. So, make sure that your calculations are fine.
>> >> >>
>> >> >> Did you check whether the range is set correctly, say, by simulating a two node scenario with a distance 'd' between them, and increasing the distance to find the minimum 'd' so that all packets are dropped? If your transmission range found this way matches the calculations, then very likely your CS-range will also match.
>> >> >>
>> >> >> ----------- Original Message ---------
>> >> >>
>> >> >> DATE: Tue, 27 Jan 2004 07:26:54
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >Hi Saikat,
>> >> >> >In your previous post, you have mentioned that you can
>> >> >> >use the same program threshold.cc to calculate
>> >> >> >RXThresh and CSThresh
>> >> >> >http://mailman.isi.edu/pipermail/ns-users/2003-November/037646.html
>> >> >> >
>> >> >> >and I did just that. However if I calculated the
>> >> >> >CSThresh for 40m, that doesn't mean the CS range is
>> >> >> >40m right.
>> >> >> >
>> >> >> >I am using the FreeSpace Prop model, is there a way to
>> >> >> >set the carrier sense range to 40m in the TCL code, if
>> >> >> >not how do I go about doing so (what paramaeters do I
>> >> >> >have to change) ?
>> >> >> >
>> >> >> >Thank You
>> >> >> >
>> >> >> >>
>> >> >> >> What do you mean by "similar *results*"? If you are
>> >> >> >> just looking at throughput, especially of some
>> >> >> >> particular node, that may remain same, or may even
>> >> >> >> decrease. However, if you count the number of
>> >> >> >> collided frames, that should be greatly reduced when
>> >> >> >> CS-range is larger.
>> >> >> >>
>> >> >> >> Secondly, how do you exactly adjust the "range" of
>> >> >> >> carrier sensing? CSThreshold is a *power* parameter
>> >> >> >> (receiver sensitivity). The actual distance is
>> >> >> >> determined by the path-loss model in conjunction
>> >> >> >> with CSThreshold.
>> >> >> >>
>> >> >> >> ----------- Original Message ---------
>> >> >> >>
>> >> >> >> DATE: Mon, 26 Jan 2004 19:57:28
>> >> >> >>> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >____________________________________________________________
>> >> >> >> Get advanced SPAM filtering on Webmail or POP Mail
>> >> >> >> ... Get Lycos Mail!
>> >> >> >> http://login.mail.lycos.com/r/referral?aid=27005
>> >> >> >>
>> >> >> >
>> >> >> >__________________________________
>> >> >> >Do you Yahoo!?
>> >> >> >Yahoo! SiteBuilder - Free web site building tool. Try it!
>> >> >> >http://webhosting.yahoo.com/ps/sb/
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> ____________________________________________________________
>> >> >> Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
>> >> >> http://login.mail.lycos.com/r/referral?aid=27005
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> ____________________________________________________________
>> >> Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
>> >> http://login.mail.lycos.com/r/referral?aid=27005
>> >>
>> >
>> >
>> 
>> ____________________________________________________________
>> Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
>> http://login.mail.lycos.com/r/referral?aid=27005
>
>



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

More information about the Ns-users mailing list