[Ns-developers] Code review request for 802.11b physical model
Ruben Merz
ruben at net.t-labs.tu-berlin.de
Tue Jun 2 14:17:01 PDT 2009
Hi Pei,
On 5/29/09 7:28 PM, Pei, Guangyu wrote:
> Hi, Ruben
>
> Thanks for reviewing. Please see my in line comments.
>
>> -----Original Message-----
>> From: Ruben Merz [mailto:ruben at net.t-labs.tu-berlin.de]
>> Sent: Friday, May 29, 2009 1:15 AM
>> To: Tom Henderson
>> Cc: Mathieu Lacage; Pei, Guangyu; ns-developers
>> Subject: Re: [Ns-developers] Code review request for 802.11b
>> physical model
>>
>> Hi Tom, hi all,
>>
>> This is nice work. In section 1.2.4, you wonder whether the
>> noise floor can be modulation dependent. I think it can, and
>> it probably does not only depend on the modulation but also
>> on the center frequency of the transmission (see the figure
>> on the bottom right of slide 8 of the talk I gave at the ns-3
>> workshop). This might actually be interesting as next
>> step: to see how the RSSI values depend on the center
>> frequency. Also, is there for you the possibility to use
>> other 802.11 hardware for the validation?
>>
>
> The short answer is yes. Figure 1.1 used Prism chipset. Since CMU
> testbed currently uses Atheros chipset, we plan to do measurements with
> ns-3 in emulation mode.
So you can run ns-3 on top of the CMU testbed?
>> Also, what kind of channel model was used for the analytical
>> results and the emulation results? Was there any fading or
>> multipath? Because, this would definitely change the results.
>> From what I read, I understand it is a free space model. I am
>> correct? For me, this also is an important issue to look at,
>> especially with most people using 802.11 link indoor.
>
> Yes, it is a AWGN channel with the control of received signal strength.
> The input signal to the receiver was the same as signal from transmitter
> except that the signal strength is set at a predefined level. You can
> view it as free space since no multipath, however, the path loss is no
> longer function of distance and it is simply the difference between
> transmitter power and received power. This is called "clear channel" in
> CMU test bed.
Ok
> I completely agree with you about importance of channel model and
> multipath. In fact, Figure 13 in CMU paper illustrated the important
> impact of dynamic equalizers under multipath. We are planning to attack
> this issue in the near future. The validation steps we took so far are
> initial steps. More results should follow.
Ok
> BTW, CMU emulator does have log-distance model with configurable path
> loss exponent and Ricean Fading Model. User can also specify multipath.
Sound great. But do we know then what would be typical path loss
exponents and multipath parameters for, say, an indoor channel?
> We plan to leverage these in our studies. Please let us know your
> thoughts about how to build a ns-3 abstraction model with dynamic
> equalizers under multipath.
I'm afraid I'm not sure. Looking at the paper from Judd and Steenkiste,
the model they use for multipath is extremely simple: it is a two ray
ground model. That is very nice to explain the behavior at the receiver
but is, in my opinion, probably not appropriate to use as a typical
indoor multipath model. It is not "rich" enough.
I would first begin with trying to understand what is a typical
multipath channel in the setting you are interested to model. From
there, I would run some physical layer simulations in order to
understand the error process. I would also like to understand how much
can the equalizer do. According the measurements in the paper by Judd
and Steenkiste, equalizers found in typical hardware today are tuned for
particular operating conditions. So there would be a sort of phase
transition, from a regime where the equalizer works to a regime where
you are outside of what the equalizer can correct.
>> Looking at Fig 1.6, I'm not sure I understand the meaning of
>> it. For unicast, you should look at the number of received
>> packets independently of the retransmissions. Then you would
>> probably get the same results than in 1.5.
>>
>
> The y-axis in both Figure 1.5 and Figure 1.6 is the number of packets
> received by network layer without errors. As RSS increases, the BER
> decreases. The retransmissions in unicast make the slope steeper.
>
> For example, let RSS1< RSS2, the packet error rate(PER) of broadcast is
> 90% for RSS1 and 50% for RSS2 respectively.
> Thus, for broadcast, 10% success rate at RSS1 and 50% success rate at
> RSS2. Let the number of retransmissions be 4 without RTS/CTS. The
> success rate for unicast can be estimated as the following:
>
> At RSS1: 1-0.9^4= 34.39% (v.s. 10% for broadcast)
> At RSS2: 1-0.5^4= 93.75% (v.s. 50% for broadcast)
>
> Thus, for same RSS1 and RSS2 pair, the packet success rate difference is
> 40% for broadcast and 59.36% for unicast. That makes the slope steeper.
>
> This example also showed that upper layer protocols may filter out the
> impact of physical layer abstractions to some extend. In this case, MAC
> layer retransmissions make the transition slope very steep. Under most
Ok, but my point was that you would not simulate the packet loss after
the MAC. You would do it after the physical layer.
> traffic loading settings, the small mismatch of slope between simulation
> and hardware measurement may not be noticeable at network layer.
Yes, agreed. But it would be interesting to show this effect.
Regards,
Ruben
> Best,
>
> Gary
--
Ruben Merz Deutsche Telekom Laboratories
http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml
More information about the Ns-developers
mailing list