Request to merge the timob wifiex project into main ns-3 repo

[Trevor Bosaw-2]

I've looked over the code located at:

http://code.nsnam.org/timob/ns-3-wifiex/

And I believe that the wifiex phy model is complementary to the main  
ns-3 wifi model, and that the two should be merged.  The main  
difference in the wifiex phy model and the main ns-3 repository is  
that it includes an improvement to the wifi state machine that allows  
for 'Capture Effect' implementation.

For those that don't know, the 'Capture Effect' in wifi is the ability  
of a receiver to synchronize to an incoming packet while it is already  
sync'ed to a packet, when the incoming packet's power is higher than  
that of the currently sync'ed packet, and is above a set threshold.  
Currently, ns-3's wifi node state machine drops any packet that is  
received while it is in the SYNC state (currently sync'ed to a  
packet). Not only does the wifiex phy model implement the 'Capture  
Effect', which more closely models actual receiver behavior, but it  
includes flags that can be set which reverts node state machine  
behavior back to how ns-3 main currently deals with things.

Most of the improvements in the wifiex project are located in the  
'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function.  
The code here is not too complicated, especially with anyone already  
familiar with the yans phy state machine, so I definitely recommend a  
quick perusal through the wifiex code.

If I get some agreement on this, I'll go ahead and prepare a patch to  
merge these two models.

-Trevor

[Faker Moatamri]

Hi Trevor,
Trevor Bosaw wrote:
> I've looked over the code located at:
>
> http://code.nsnam.org/timob/ns-3-wifiex/
I tried to run the code from this repository and it give me an error
(Linux Fedora 10 with g++-4.3.2 and it fails with the following message:
../src/internet-stack/nsc-tcp-socket-impl.cc: In member function
‘virtual ns3::Ptr<ns3::Packet> ns3::NscTcpSocketImpl::RecvFrom(uint32_t,
uint32_t, ns3::Address&)’:
../src/internet-stack/nsc-tcp-socket-impl.cc:451: error: ‘class
ns3::Packet’ has no member named ‘FindFirstMatchingTag’
../src/internet-stack/nsc-tcp-socket-impl.cc: In member function ‘bool
ns3::NscTcpSocketImpl::ReadPendingData()’:
../src/internet-stack/nsc-tcp-socket-impl.cc:603: error: ‘class
ns3::Packet’ has no member named ‘AddTag’
I guess that it is easy to fix...

I also noticed that the code was merged with revision 4571 and we
currentely are in revision 5467, we need a patch for wifiex based on the
latest revision which included a lot of changes compared to revision 4571.

> And I believe that the wifiex phy model is complementary to the main
> ns-3 wifi model, and that the two should be merged. The main
> difference in the wifiex phy model and the main ns-3 repository is
> that it includes an improvement to the wifi state machine that allows
> for 'Capture Effect' implementation.
>
> For those that don't know, the 'Capture Effect' in wifi is the ability
> of a receiver to synchronize to an incoming packet while it is already
> sync'ed to a packet, when the incoming packet's power is higher than
> that of the currently sync'ed packet, and is above a set threshold.
> Currently, ns-3's wifi node state machine drops any packet that is
> received while it is in the SYNC state (currently sync'ed to a
> packet). Not only does the wifiex phy model implement the 'Capture
> Effect', which more closely models actual receiver behavior, but it
> includes flags that can be set which reverts node state machine
> behavior back to how ns-3 main currently deals with things.

Sounds very interesting, if the code is good I will give it +1 to be merged.
>
> Most of the improvements in the wifiex project are located in the
> 'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function.
> The code here is not too complicated, especially with anyone already
> familiar with the yans phy state machine, so I definitely recommend a
> quick perusal through the wifiex code.
>
> If I get some agreement on this, I'll go ahead and prepare a patch to
> merge these two models.
I encourage you to produce a patch for these models based on the latest
ns-3-dev tree as soon as possible. Please remember that we have less
than three weeks left for the open phase, the fastest you provide us
with a patch, the more chances you have to include the models into
NS-3.7 release.
>
> -Trevor
Best regards,
Faker Moatamri

[Mathieu Lacage]

is timo officially not going to work on this anymore ?

Mathieu

On Wed, 2009-10-28 at 16:41 -0700, Trevor Bosaw wrote:

> I've looked over the code located at:
>
> http://code.nsnam.org/timob/ns-3-wifiex/
>
> And I believe that the wifiex phy model is complementary to the main  
> ns-3 wifi model, and that the two should be merged.  The main  
> difference in the wifiex phy model and the main ns-3 repository is  
> that it includes an improvement to the wifi state machine that allows  
> for 'Capture Effect' implementation.
>
> For those that don't know, the 'Capture Effect' in wifi is the ability  
> of a receiver to synchronize to an incoming packet while it is already  
> sync'ed to a packet, when the incoming packet's power is higher than  
> that of the currently sync'ed packet, and is above a set threshold.  
> Currently, ns-3's wifi node state machine drops any packet that is  
> received while it is in the SYNC state (currently sync'ed to a  
> packet). Not only does the wifiex phy model implement the 'Capture  
> Effect', which more closely models actual receiver behavior, but it  
> includes flags that can be set which reverts node state machine  
> behavior back to how ns-3 main currently deals with things.
>
> Most of the improvements in the wifiex project are located in the  
> 'ns2ext-wifi-phy.cc' file, under the 'StartReceivePacket' function.  
> The code here is not too complicated, especially with anyone already  
> familiar with the yans phy state machine, so I definitely recommend a  
> quick perusal through the wifiex code.
>
> If I get some agreement on this, I'll go ahead and prepare a patch to  
> merge these two models.
>
> -Trevor

[Trevor Bosaw-2]

Hey,

I've sent an email off to Timo to see if he is still working on this  
or not.  The last change was done four months ago.


Also, as for the error in compiling the code, the ncs-tcp-socket-
impl.cc file, which is where the error is generated, is not part of my  
planned patch.  Essentially I plan to move over solely the capture  
effect code for now, that way I'll be able to make the three week  
deadline.

-Trevor

[Pavel Boyko]

  Hi, Trevor,

  I'm happy to hear that you plan to merge yans & wifiex PHY models, thank you!

  But apart of capture effect and explicit preamble modeling (by the way -- do
you plan to add explicit preamble to yans?) wifiex includes simple threshold-
based interference model. Since YANS interference calculations are performance
bottleneck in large networks, I propose to keep interference model from wifiex
as an option. It would be great if you can do this too.

  Good luck,
  Pavel

On Friday 30 October 2009 07:24:17 am Trevor Bosaw wrote:

> Hey,
>
> I've sent an email off to Timo to see if he is still working on this
> or not.  The last change was done four months ago.
>
>
> Also, as for the error in compiling the code, the ncs-tcp-socket-
> impl.cc file, which is where the error is generated, is not part of my
> planned patch.  Essentially I plan to move over solely the capture
> effect code for now, that way I'll be able to make the three week
> deadline.
>
> -Trevor

[Timo Bingmann-2]

Hello guys,

thanks for "waking me up" :). No really, I was absent from this whole world,
including reality, for the last few months due to an exam, which I finally
finished just last week.

I am going to work on merging some of my code into the mainstream. However,
I'm definitely desynched from current development, as is my repo.

I believe the feature most people are interested in is the frame capture.
This, I believe, I have no not integrated into the YansWifiPhy yet, because it
is conceptually incompatible.

Nevertheless, I believe we can still combine the models by adding a capture
threshold separate from the PER calculations. Practical simulations will
benefit from this approach.

What to do with the Ns2ExtWifiPhy I don't quite know. There is much duplicate
code from YansWifiPhy, which makes maintenance difficult. What do the wifi-
maintainers think?

I also remember the TrafficApplication, which is very simple but very useful.
But its a separate topic.

There is also an approach to adding TXOP limits and burst in that wifiex (or in
my unpublished repo?), that I will review later on.

Greetings,
Timo

On Friday 30 October 2009 10:04:47 Pavel Boyko wrote:

>   Hi, Trevor,
>
>   I'm happy to hear that you plan to merge yans & wifiex PHY models, thank
>  you!
>
>   But apart of capture effect and explicit preamble modeling (by the way --
>  do you plan to add explicit preamble to yans?) wifiex includes simple
>  threshold- based interference model. Since YANS interference calculations
>  are performance bottleneck in large networks, I propose to keep
>  interference model from wifiex as an option. It would be great if you can
>  do this too.
>
>   Good luck,
>   Pavel
>
> On Friday 30 October 2009 07:24:17 am Trevor Bosaw wrote:
> > Hey,
> >
> > I've sent an email off to Timo to see if he is still working on this
> > or not.  The last change was done four months ago.
> >
> >
> > Also, as for the error in compiling the code, the ncs-tcp-socket-
> > impl.cc file, which is where the error is generated, is not part of my
> > planned patch.  Essentially I plan to move over solely the capture
> > effect code for now, that way I'll be able to make the three week
> > deadline.
> >
> > -Trevor

[Trevor Bosaw-2]

So I've talked with Timo, and he apparently just finished up with his  
exams, and is now willing to resume work on wifiex.  It seems that any  
attempts to merge wifiex and ns-3 will come from him, so I would  
expect he'll have a patch sometime soon.

[Mathieu Lacage]

On Tue, 2009-11-03 at 16:48 +0100, Timo Bingmann wrote:

> I believe the feature most people are interested in is the frame capture.
> This, I believe, I have no not integrated into the YansWifiPhy yet, because it
> is conceptually incompatible.
>
> Nevertheless, I believe we can still combine the models by adding a capture
> threshold separate from the PER calculations. Practical simulations will
> benefit from this approach.
>
> What to do with the Ns2ExtWifiPhy I don't quite know. There is much duplicate
> code from YansWifiPhy, which makes maintenance difficult. What do the wifi-
> maintainers think?

I have a dim memory of what your code is doing: it's pretty clear that
maintainance is important so, if it's an issue, we need to deal with it.
I am also concerned about not making the default wifi PHY model too
complex so, I would like to make the default model not create more
events than it already is creating. Could you refresh my memory about
what you are doing ? Maybe you could also repost here a link to your
master thesis which, I presume, talks about your work at length.

> There is also an approach to adding TXOP limits and burst in that wifiex (or in
> my unpublished repo?), that I will review later on.

I have never seen that code so, I can't comment on it.

Mathieu

[Tom Henderson-2]

Timo Bingmann wrote:

> Hello guys,
>
> thanks for "waking me up" :). No really, I was absent from this whole world,
> including reality, for the last few months due to an exam, which I finally
> finished just last week.
>
> I am going to work on merging some of my code into the mainstream. However,
> I'm definitely desynched from current development, as is my repo.
>
> I believe the feature most people are interested in is the frame capture.
> This, I believe, I have no not integrated into the YansWifiPhy yet, because it
> is conceptually incompatible.
>
> Nevertheless, I believe we can still combine the models by adding a capture
> threshold separate from the PER calculations. Practical simulations will
> benefit from this approach.

Timo,
Can you elaborate a bit on the above?  Why do you think it is
conceptually incompatible to merge these models?  Are there further
extensions planned that would make it incompatible?

- Tom

[Nicola Baldo-3]

Hi Trevor,

Trevor Bosaw wrote:

> I've looked over the code located at:
>
> http://code.nsnam.org/timob/ns-3-wifiex/
>
> And I believe that the wifiex phy model is complementary to the main
> ns-3 wifi model, and that the two should be merged.  The main difference
> in the wifiex phy model and the main ns-3 repository is that it includes
> an improvement to the wifi state machine that allows for 'Capture
> Effect' implementation.
>
> For those that don't know, the 'Capture Effect' in wifi is the ability
> of a receiver to synchronize to an incoming packet while it is already
> sync'ed to a packet, when the incoming packet's power is higher than
> that of the currently sync'ed packet, and is above a set threshold.  
> Currently, ns-3's wifi node state machine drops any packet that is
> received while it is in the SYNC state (currently sync'ed to a packet).
> Not only does the wifiex phy model implement the 'Capture Effect', which
> more closely models actual receiver behavior, but it includes flags that
> can be set which reverts node state machine behavior back to how ns-3
> main currently deals with things.
>

I agree that the Capture Effect modeling is a nice feature, but I do not
agree in adding the threshold on the power of the new packet. In my
opinion, you should re-sync on the new packet whenever it is stronger
than the previous (regardless of the difference). The interference
modeling in YansWifiPhy will take care of discarding the packet later if
it is not enough stronger than the other superimposed packet(s).

Regards,

Nicola

[Jens Mittag-2]

Am 12.11.2009 17:53, schrieb Nicola Baldo:

> Hi Trevor,
>
> Trevor Bosaw wrote:
>> I've looked over the code located at:
>>
>> http://code.nsnam.org/timob/ns-3-wifiex/
>>
>> And I believe that the wifiex phy model is complementary to the main
>> ns-3 wifi model, and that the two should be merged.  The main
>> difference in the wifiex phy model and the main ns-3 repository is
>> that it includes an improvement to the wifi state machine that allows
>> for 'Capture Effect' implementation.
>>
>> For those that don't know, the 'Capture Effect' in wifi is the
>> ability of a receiver to synchronize to an incoming packet while it
>> is already sync'ed to a packet, when the incoming packet's power is
>> higher than that of the currently sync'ed packet, and is above a set
>> threshold.  Currently, ns-3's wifi node state machine drops any
>> packet that is received while it is in the SYNC state (currently
>> sync'ed to a packet). Not only does the wifiex phy model implement
>> the 'Capture Effect', which more closely models actual receiver
>> behavior, but it includes flags that can be set which reverts node
>> state machine behavior back to how ns-3 main currently deals with
>> things.
>>
>
> I agree that the Capture Effect modeling is a nice feature, but I do
> not agree in adding the threshold on the power of the new packet. In
> my opinion, you should re-sync on the new packet whenever it is
> stronger than the previous (regardless of the difference). The
> interference modeling in YansWifiPhy will take care of discarding the
> packet later if it is not enough stronger than the other superimposed
> packet(s).
>
> Regards,
>
> Nicola
>

Hi Nicola

I understand your point, but capturing is no technical issue, not a
"capability" itself and rather the trade-off between "staying synced to
the first packet and hoping that FEC will solve the bit errors
introduced by the interfering stronger packet" and "switching to the new
frame and hoping that this will be more lucky than the first one".
Capturing is NOT about what is possible to decode but rather WHICH
strategic decision the reciever should do, i.e. which packet frame is
favored over the other. As experimental studies have shown, this
threshold is not based on any modulation techniques, but artificially
selected by Atheros. Not adding this threshold would yield to anything
but not to a model that reflects capturing...

Jens

--
Dipl.-Inform. Jens Mittag
University of Karlsruhe
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: [phone]
Fax:   [phone]

http://dsn.tm.uni-karlsruhe.de/

[Nicola Baldo-3]

Hi Jens,

Jens Mittag wrote:

>
> I understand your point, but capturing is no technical issue, not a
> "capability" itself and rather the trade-off between "staying synced
> to the first packet and hoping that FEC will solve the bit errors
> introduced by the interfering stronger packet" and "switching to the
> new frame and hoping that this will be more lucky than the first
> one". Capturing is NOT about what is possible to decode but rather
> WHICH strategic decision the reciever should do, i.e. which packet
> frame is favored over the other. As experimental studies have shown,
> this threshold is not based on any modulation techniques, but
> artificially selected by Atheros. Not adding this threshold would
> yield to anything but not to a model that reflects capturing...

We should clarify which type of capture we are talking about. In [1]
(which I guess that you know well) two types are mentioned: preamble
capture (Section 3.3.1) and frame body capture (Section 3.3.2).

The comments in my previous email were relevant to preable capture. For
this case, I argue that the stronger signal will get the highest
correlation peak in the detection of the preamble, and hence will be the
  one that the receiving PHY synchronizes onto, no matter how small the
difference in signal power. This is why I proposed not to have any
threshold.

I guess you are talking about frame body capture; for this case, I agree
that a "capture threshold" makes sense, because if the difference in
power is too small then the new transmission cannot be noticed.

As a side note, you mention that capture is a "trade-off" and a
"strategic decision", but actually I do not think that the device has
any choice in the case of frame body capture. When a significantly
stronger signal arrives during frame body reception of the previous
frame, the AGC unlocks (I guess this is the events that triggers the
frame body capture, by the way). I am not confident on how atheros
chipsets handle this case, but I know how prism chipsets do: since an
AGC unlock event screws up the whole rx process, no matter how strong
your FEC is, the baseband will abort reception. So the previous frame is
lost in any case; the reception of the new frame can be attempted if the
baseband processor can re-initialize and do preamble detection fast
enough. The prism chipset can't do that; I guess atheros can.


Nicola


[1] Qi Chen, Felix Schmidt-Eisenlohr, Daniel Jiang, "Overhaul of IEEE
802.11 Modeling and Simulation in NS-2"

[Jens Mittag-2]

Hi Nicola!

Nicola Baldo schrieb:

> We should clarify which type of capture we are talking about. In [1]
> (which I guess that you know well) two types are mentioned: preamble
> capture (Section 3.3.1) and frame body capture (Section 3.3.2).
>
> The comments in my previous email were relevant to preable capture. For
> this case, I argue that the stronger signal will get the highest
> correlation peak in the detection of the preamble, and hence will be the
>  one that the receiving PHY synchronizes onto, no matter how small the
> difference in signal power. This is why I proposed not to have any
> threshold.
>
> I guess you are talking about frame body capture; for this case, I agree
> that a "capture threshold" makes sense, because if the difference in
> power is too small then the new transmission cannot be noticed.
>
> As a side note, you mention that capture is a "trade-off" and a
> "strategic decision", but actually I do not think that the device has
> any choice in the case of frame body capture. When a significantly
> stronger signal arrives during frame body reception of the previous
> frame, the AGC unlocks (I guess this is the events that triggers the
> frame body capture, by the way). I am not confident on how atheros
> chipsets handle this case, but I know how prism chipsets do: since an
> AGC unlock event screws up the whole rx process, no matter how strong
> your FEC is, the baseband will abort reception. So the previous frame is
> lost in any case; the reception of the new frame can be attempted if the
> baseband processor can re-initialize and do preamble detection fast
> enough. The prism chipset can't do that; I guess atheros can.
>

Yes, that's what I was trying to explain. But even with your
argumentation we need a threshold (imho), though you would name it "AGC
unlock threshold".

How AGC works is from my understanding/experience a matter of hardware
implementation. And depending on the supported power range of the AGC,
the "AGC unlock" happens earlier or later, right? With respect to the
strategic decision, you could design your AGC to unlock after only a 5dB
gain or only after a 10dB gain. From that perspective, its a strategic
decision, though it has been made during the chipset design... (please
correct me if I am wrong, I might be mistaken)

Considering capture in general: from my knowledge and discussion with
people who are more experienced in the lowest layers, capture is enabled
by having two decoding units for the incoming signal. Both will try to
detect a frame (either by looking for a steep rise of the energy or by
correlating the signal to the known preamble sequence). If a frame is
detected, one unit starts the reception, and the other unit continues to
look for preambles. In case a stronger preamble is detected (either by a
steep rise of the energy again, or by a high correlation), the chip can
start to decode the new frame and skip the previous one, or just stick
with the current frame. So capturing is also related to signal
detection. Further details on signal detecting can be found in [1]
below, which explains the techniques that are used in the Atheros chipset.

Conclusion: I still believe that we should have a threshold for preamble
capture.

cheers
 Jens

[1] Ilenia Tinnirello, Domenico Giustiniano, Luca Scalia, Giuseppe
Bianchi: On the side-effects of proprietary solutions for fading and
interference mitigation in IEEE 802.11b/g outdoor links. Computer
Networks 53(2): 141-152 (2009)

--
Dipl.-Inform. Jens Mittag
Karlsruhe Institute of Technology (KIT)
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: [phone]
Fax:   [phone]

http://dsn.tm.uni-karlsruhe.de/

[Nicola Baldo-3]

Hi Jens,


> How AGC works is from my understanding/experience a matter of hardware
> implementation. And depending on the supported power range of the AGC,
> the "AGC unlock" happens earlier or later, right? With respect to the
> strategic decision, you could design your AGC to unlock after only a 5dB
> gain or only after a 10dB gain. From that perspective, its a strategic
> decision, though it has been made during the chipset design... (please
> correct me if I am wrong, I might be mistaken)

I don't know for sure... your hypothesis makes sense, but I guess that
also the characteristics of the demodulator constrain the design of the
AGC. We should ask some PHY layer people ;-)

>
> Considering capture in general: from my knowledge and discussion with
> people who are more experienced in the lowest layers, capture is enabled
> by having two decoding units for the incoming signal. Both will try to
> detect a frame (either by looking for a steep rise of the energy or by
> correlating the signal to the known preamble sequence). If a frame is
> detected, one unit starts the reception, and the other unit continues to
> look for preambles. In case a stronger preamble is detected (either by a
> steep rise of the energy again, or by a high correlation), the chip can
> start to decode the new frame and skip the previous one, or just stick
> with the current frame. So capturing is also related to signal
> detection. Further details on signal detecting can be found in [1]
> below, which explains the techniques that are used in the Atheros chipset.
>
> Conclusion: I still believe that we should have a threshold for preamble
> capture.
>

 From the paper that you cited I understand that atheros devices detect
the start of a new frame using either AGC jump or preamble detection.
For prism devices I know that AGC jump, Preamble Detection and Energy
Detection can be all used for frame start detection, with different
logical combinations (e.g., logical OR, or logical AND of some or all
events).
On the other hand, YansWifiPhy currently implements Energy Detection
only. Your proposed change would introduce AGC for capture only, so I
think it would lead to a poorly consistent YansWifiPhy, with an ideal
model for transitions IDLE->SYNC but a more real-world-oriented model
for re-SYNC (i.e., capture) events.

If you can produce a patch that:
1) introduces the modeling of preamble detection (PD) and AGC
2) allows doing transitions from IDLE to SYNC according to different
logical combinations of ED, PD and AGC jumps
3) uses PD and AGC jumps for preamble capture
4) uses AGC jumps for frame body capture
then you can count on my +1.

Regards,

Nicola

[Jens Mittag-2]

Hi Nicola!

Nicola Baldo schrieb:

> From the paper that you cited I understand that atheros devices detect
> the start of a new frame using either AGC jump or preamble detection.
> For prism devices I know that AGC jump, Preamble Detection and Energy
> Detection can be all used for frame start detection, with different
> logical combinations (e.g., logical OR, or logical AND of some or all
> events).
> On the other hand, YansWifiPhy currently implements Energy Detection
> only. Your proposed change would introduce AGC for capture only, so I
> think it would lead to a poorly consistent YansWifiPhy, with an ideal
> model for transitions IDLE->SYNC but a more real-world-oriented model
> for re-SYNC (i.e., capture) events.
>
> If you can produce a patch that:
> 1) introduces the modeling of preamble detection (PD) and AGC
> 2) allows doing transitions from IDLE to SYNC according to different
> logical combinations of ED, PD and AGC jumps
> 3) uses PD and AGC jumps for preamble capture
> 4) uses AGC jumps for frame body capture
> then you can count on my +1.

One comment in advance: I don't see the need to implement all the
details of the paper I cited in my previous mail (accurate signal
detection...) because we can't implement them in a packet-level
simulator. I used this reference only to support my argumentation. I
believe that a simple threshold (either fixed or as a
continuous/stepwise function) is the appropriate way to cover the
effects of all the underlying details on a packet-level basis.

So, regarding your proposed/desired patch with PD, ED and AGC jumps: (1)
 believe that these mechanisms can not be modeled in a packet-level
simulator, because we would need to operate on time samples and
individual symbols to do so. The time samples are required to execute
any correlation algorithms. (2) I believe that these mechanisms do
different things technically, but with the same logical
objective/result: frame detection. Due to this, we can capture this
behavior only statistically in our models. Further, we can only capture
it based on the only physical layer characterization that we have in
NS-3 wifi: the SINR.

Our research group has recently implemented a physical layer for OFDM
wifi that goes down to the time sample level by breaking the abstraction
of a packet and implementing the transceiver technology entirely in
software.

However, again, since we are not working on time samples in standard
NS-3 but on a packet-level basis with per-packet received signal
strengths, we have to make a distinction between what is happening in a
real hardware and the way we capture the effect of these internals. We
can capture them only statistically. Using a threshold is therefore from
my experience, and according to experimental results [1], a reasonable
abstraction and modeling approach. Or do you know an example where this
approach would fail? If yes, please elaborate.

Of course, following [2], the threshold can also be implemented as a
function of the SINR instead of a fixed threshold. But this doesn't
change in my opinion the fact of having a threshold.

Jens

[1] "An experimental study on the capture effect in 802.11a networks",
Lee et. al, ACM WiNTECH Workshop 2007
Revised version:
http://mmlab.snu.ac.kr/~jklee/papers/wintech405-lee-rev080321.pdf

[2] "Revamping the IEEE 802.11a PHY simulation models", Ryu et. al,
2008, MSWiM
--
Dipl.-Inform. Jens Mittag
Karlsruhe Institute of Technology (KIT)
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: [phone]
Fax:   [phone]

http://dsn.tm.uni-karlsruhe.de/

[Nicola Baldo-3]

Hi Jens,

Jens Mittag wrote:

>
> One comment in advance: I don't see the need to implement all the
> details of the paper I cited in my previous mail (accurate signal
> detection...) because we can't implement them in a packet-level
> simulator. I used this reference only to support my argumentation. I
> believe that a simple threshold (either fixed or as a
> continuous/stepwise function) is the appropriate way to cover the
> effects of all the underlying details on a packet-level basis.
>
> So, regarding your proposed/desired patch with PD, ED and AGC jumps: (1)
>  believe that these mechanisms can not be modeled in a packet-level
> simulator, because we would need to operate on time samples and
> individual symbols to do so. The time samples are required to execute
> any correlation algorithms. (2) I believe that these mechanisms do
> different things technically, but with the same logical
> objective/result: frame detection. Due to this, we can capture this
> behavior only statistically in our models. Further, we can only capture
> it based on the only physical layer characterization that we have in
> NS-3 wifi: the SINR.
>
> Our research group has recently implemented a physical layer for OFDM
> wifi that goes down to the time sample level by breaking the abstraction
> of a packet and implementing the transceiver technology entirely in
> software.
>
> However, again, since we are not working on time samples in standard
> NS-3 but on a packet-level basis with per-packet received signal
> strengths, we have to make a distinction between what is happening in a
> real hardware and the way we capture the effect of these internals. We
> can capture them only statistically. Using a threshold is therefore from
> my experience, and according to experimental results [1], a reasonable
> abstraction and modeling approach. Or do you know an example where this
> approach would fail? If yes, please elaborate.
>
> Of course, following [2], the threshold can also be implemented as a
> function of the SINR instead of a fixed threshold. But this doesn't
> change in my opinion the fact of having a threshold.
>

I am NOT proposing to go beyond packet-level simulations. I agree with
you that simulating things on a symbol scale is overkill.

What I meant is the following:

1) Energy Detection (ED) is comparing absolute rx power against a
threshold. This is what YansWifiPhy currently provides for synchronization.

2) Preamble Detection (PD) is currently not modeled in YansWifiPhy. A
simple way of implementing it is to compare SINR with a threshold; if
SINR > threshold, then the preamble can be detected successfully,
otherwise not; the threshold will typically be below 0dB. Note that,
even if a threshold model is used in both cases, PD can give different
output than ED in several situations. A more complex model for PD (but
still feasible in a network simulator) would be to use a detection
probability as a function of SINR. Also, preamble length should be
accounted for when determining the threshold (or the detection probability).

3) AGC is currently not modeled. A simple way of implementing it is a
state machine which fires an event whenever there is a jump on the total
energy detected at the receiver (including noise). The events fired by
the AGC can be used for synchronization (i.e., transition from IDLE to
SYNC) as well as for frame body capture.

That's it. In practical terms, we agree on most stuff (i.e., using
thresholds). My point is that rather than just saying "let's put a
threshold for capture" I would prefer to clearly state what is the
underlying phenomenon that we are trying to model (ED, PD, AGC). And, if
we model a phenomenon (e.g., AGC), try to be consistent and consider it
  in all cases in which it is relevant (i.e., not only for capture, but
also for synchronization, and for aborting RX if the device does not
support frame body capture).

Nicola

[Jens Mittag-2]

Hi Nicola,

> I am NOT proposing to go beyond packet-level simulations. I agree with
> you that simulating things on a symbol scale is overkill.
>
> What I meant is the following:
>
> 1) Energy Detection (ED) is comparing absolute rx power against a
> threshold. This is what YansWifiPhy currently provides for synchronization.
>
> 2) Preamble Detection (PD) is currently not modeled in YansWifiPhy. A
> simple way of implementing it is to compare SINR with a threshold; if
> SINR > threshold, then the preamble can be detected successfully,
> otherwise not; the threshold will typically be below 0dB. Note that,
> even if a threshold model is used in both cases, PD can give different
> output than ED in several situations. A more complex model for PD (but
> still feasible in a network simulator) would be to use a detection
> probability as a function of SINR. Also, preamble length should be
> accounted for when determining the threshold (or the detection
> probability).

Ah, now I get you ;) When you say energy detection (ED) you are talking
about an absolute threshold. I understood it as a steep rise of the
signal energy, which is relative again.

One question: do you see the energy detection threshold as an artificial
value that can be set by a network designer to suppress nodes from a
different network that is close to your own network? Or do you see it as
a technological restriction, that the hardware can only decode above
this energy level? Or why has it been introduced in YansWifiPhy? Is it
an artifact from the old NS-2 implementation (before the changes from
Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold?

In the code of Timo Bingmann (he worked in our group during his diploma
thesis), we do not consider energy detection at all and model only
preamble detection... the energy detection threshold is from our
understanding implicitly given by the noise floor and the SINR threshold
for the preamble.

Thanks for your clarification
 Jens

--
Dipl.-Inform. Jens Mittag
Karlsruhe Institute of Technology (KIT)
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: [phone]
Fax:   [phone]

http://dsn.tm.uni-karlsruhe.de/

[Mathieu Lacage]

On Tue, 2009-11-17 at 10:34 +0100, Jens Mittag wrote:

> Our research group has recently implemented a physical layer for OFDM
> wifi that goes down to the time sample level by breaking the abstraction
> of a packet and implementing the transceiver technology entirely in
> software.

Hint, hint: It would be nice to see this PHY layer integrated in the
ns-3 wifi module :)

Mathieu

[Nicola Baldo-3]

> Ah, now I get you  ;)  When you say energy detection (ED) you are talking
> about an absolute threshold. I understood it as a steep rise of the
> signal energy, which is relative again.

I didn't invent that definition by myself ;-)

The process of synchronizing upon reception is defined in IEEE
802.11-2007 section 15.2.7. Two primitives can be used for this purpose:
PMD_ED and PMD_SQ.

PMD_ED (section 15.4.5.13) indicates "that the receiver has detected RF
energy [...] that is above a predefined threshold".

PMD_SQ (15.4.5.11) "provides to the PLCP and MAC entity the SQ of the
DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY
achieves code lock and shall be held until the next code lock acquisition."
In other words, PMD_SQ is fired when preamble is detected.

Note that the same primitives (PMD_ED and PMD_SQ) are used for Clear
Channel Assessment (CCA). Also note that things change slightly for PHY
specifications other than DSSS.


> One question: do you see the energy detection threshold as an artificial
> value that can be set by a network designer to suppress nodes from a
> different network that is close to your own network?

Yes, that's also the way it is defined in the standard.


> Or do you see it as
> a technological restriction, that the hardware can only decode above
> this energy level?

No.


> Or why has it been introduced in YansWifiPhy? Is it
> an artifact from the old NS-2 implementation (before the changes from
> Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold?

I think there is some confusion about the current YansWifiPhy.
Have a look for instance at the discussion for bug 689:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=689

the fact is that we have an "EnergyDetectionThreshold" and a
"CcaMode1Threshold". The standard (section 15.4.8.4) says that CCA mode
1 corresponds to the use of ED only (no preamble detection).
So CccaMode1Threshold is the one for ED, and what about
EnergyDetectionThreshold?

I am tempted to reopen bug 689...


>
> In the code of Timo Bingmann (he worked in our group during his diploma
> thesis), we do not consider energy detection at all and model only
> preamble detection...

That's a possible choice. The standard allows the use of PMD_SQ alone,
both for reception (section 15.2.7) and CCA (section 15.4.8.4). Note
that the standard also allows the use of PMD_ED alone, I think that
YansWifiPhy was designed with this latter choice.


> the energy detection threshold is from our
> understanding implicitly given by the noise floor and the SINR threshold
> for the preamble.

This reasoning is not correct. The standard allows you to set the ED
threshold high enough so that low power signals for which preamble can
be detected will still fail ED. As you mentioned earlier, this is done
so that you can transmit over weak signals and achieve a higher channel
utilization in dense deployments. Also note that, if we model preamble
reception with a SNR threshold, the value of this threshold will be in
practice imposed by the PHY specifications (type of preamble and length).


Nicola

[Jens Mittag-2]

Hi Nicola!

Nicola Baldo schrieb:

>> Ah, now I get you  ;)  When you say energy detection (ED) you are talking
>> about an absolute threshold. I understood it as a steep rise of the
>> signal energy, which is relative again.
>
> I didn't invent that definition by myself ;-)
>
> The process of synchronizing upon reception is defined in IEEE
> 802.11-2007 section 15.2.7. Two primitives can be used for this purpose:
> PMD_ED and PMD_SQ.
>
> PMD_ED (section 15.4.5.13) indicates "that the receiver has detected RF
> energy [...] that is above a predefined threshold".
>
> PMD_SQ (15.4.5.11) "provides to the PLCP and MAC entity the SQ of the
> DSSS PHY PN code correlation. The SQ shall be sampled when the DSSS PHY
> achieves code lock and shall be held until the next code lock acquisition."
> In other words, PMD_SQ is fired when preamble is detected.
>
> Note that the same primitives (PMD_ED and PMD_SQ) are used for Clear
> Channel Assessment (CCA). Also note that things change slightly for PHY
> specifications other than DSSS.

Great, now I understand the reason why I did not understand this. Our
group doesn't look at DSSS mode and only on OFDM operation (Section 17
in the IEEE Standard). There we don't have PMD_ED and PMD_SQ, but only
PHY-CCA and (not explicitly mentioned) the PMD_CS.

>> Or why has it been introduced in YansWifiPhy? Is it
>> an artifact from the old NS-2 implementation (before the changes from
>> Schmidt-Eisenlohr et. al) where we had a Rx and a Cs threshold?
>
> I think there is some confusion about the current YansWifiPhy.
> Have a look for instance at the discussion for bug 689:
> http://www.nsnam.org/bugzilla/show_bug.cgi?id=689
>
> the fact is that we have an "EnergyDetectionThreshold" and a
> "CcaMode1Threshold". The standard (section 15.4.8.4) says that CCA mode
> 1 corresponds to the use of ED only (no preamble detection).
> So CccaMode1Threshold is the one for ED, and what about
> EnergyDetectionThreshold?
>
> I am tempted to reopen bug 689...

I guess the confusing comes from the different PHY specifications (as
stated above): OFDM mode has only PHY-CCA and PMD_CS, whereas DSSS has
(optionally) also PMD_ED and PMD_SQ to support PHY-CCA. How about having
two different PHY implementation classes, one for OFDM and one for DSSS?

Of course we would have duplicate code, but this way it would be a clear
separation of the two modes, and more obvious to the user. And it would
be easier to have default parameters for both modes... (from my
knowledge/experience the BER functions are also different).

>> In the code of Timo Bingmann (he worked in our group during his diploma
>> thesis), we do not consider energy detection at all and model only
>> preamble detection...
>
> That's a possible choice. The standard allows the use of PMD_SQ alone,
> both for reception (section 15.2.7) and CCA (section 15.4.8.4). Note
> that the standard also allows the use of PMD_ED alone, I think that
> YansWifiPhy was designed with this latter choice.

>> the energy detection threshold is from our
>> understanding implicitly given by the noise floor and the SINR threshold
>> for the preamble.
>
> This reasoning is not correct. The standard allows you to set the ED
> threshold high enough so that low power signals for which preamble can
> be detected will still fail ED. As you mentioned earlier, this is done
> so that you can transmit over weak signals and achieve a higher channel
> utilization in dense deployments. Also note that, if we model preamble
> reception with a SNR threshold, the value of this threshold will be in
> practice imposed by the PHY specifications (type of preamble and length).

I agree, with this reasoning, you would definitely need to model the
energy detection threshold explicitly to support the suppression.
However, this suppression is apparently only standardized for DSSS and
not for OFDM mode.

Jens

--
Dipl.-Inform. Jens Mittag
Karlsruhe Institute of Technology (KIT)
Institute of Telematics
Decentralized Systems and Network Services Research Group

Engesserstr. 2, 76131 Karlsruhe, Germany
Building 20.50, Room 112

Phone: [phone]
Fax:   [phone]

http://dsn.tm.uni-karlsruhe.de/