On 09/03/2015 07:03 AM, Rafael Araújo da Silva wrote:
> Hi Yannis! Thank you for your support.
>
>
> Apparently I swapped the concepts. If the ED parameter is the ability to
> detect and decode a packet so I must set it to a greater value and set
> the CCAModelThreshold with a lower value.
Yes, the terminology appears to be a bit different from the standard and
literature. The setting of these parameters is discussed below.
The ns-3 attribute CcaMode1Threshold corresponds to what the standard
calls the "ED threshold" for CCA Mode 1. In section
16.4.8.5: "CCA
Mode 1: Energy above threshold. CCA shall report a busy medium upon
detection of any energy above the ED threshold." This is how it is
being used in ns-3 (at the maybeCcaBusy: point in the code).
There is a "noise ED threshold" in the standard for non-Wi-Fi signals,
and this is usually set to 20 dB greater than the "carrier sense ED
threshold". However, the model doesn't appear to support this, and
perhaps it is because there are no 'foreign' signals in YansWifi model--
everything is a Wi-Fi signal.
In the standard, there is also what is called the "minimum modulation
and coding rate sensitivity" in section 18.3.10.6 CCA requirements.
This is the -82 dBm requirement for 20 MHz channels. This seems to be
analogous to the EnergyDetectionThreshold attribute in ns-3. CCA busy
state is not raised in ns-3 Yans model when this threshold is exceeded
but instead RX state is immediately reached, since it is assumed that
sync always succeeds in this model. Even if the PLCP reception fails,
the channel state is still held in RX until EndReceive.
In ns-3, the values of these attributes are set to small default values
(-96 dBm for EnergyDetectionThreshold and -99 dBm for
CcaMode1Threshold). So, if a signal comes in at > -96 dBm and the state
is IDLE or CCA BUSY, this model will lock onto it for the signal
duration and raise RX state. If it comes in at <= -96 dBm but >= -99
dBm, it will definitely raise CCA BUSY but not RX state. If it comes in
< -99 dBm, it gets added to the interference tracker and, by itself, it
will not raise CCA BUSY, but maybe a later signal will contribute more
power so that the threshold of -99 dBm is reached at a later time.
So, it seems to me that the ns-3 EnergyDetectionThreshold attribute
should be set to a value greater than the CcaMode1Threshold attribute,
and should probably be the power level at which the model is assumed to
be able to possibly decode the PLCP header successfully. The
CcaMode1Threshold attribute should probably be set to the power level at
which the model is assumed to be able to detect the presence of a Wi-Fi
preamble.
>
>
> However, even when the power of the received packet is far below the
> CCAModelThreshold the method NotifyRxDrop is called. This seems weird to
> me. How could drop a packet that was not even detected?
I see your point, but it is also possible to take the position that the
RxDrop is indeed happening in ns-3; the channel delivers a packet to the
Phy object, and the ns-3::Packet object is in fact dropped. Perhaps it
needs to be clarified in NotifyRxDrop that this is called even for
received packets that are below the (logical) detection threshold.
>
>
> But my goal is different. I want to know how much is the interference
> caused by nodes that are at a distance where the power of received
> signal is below the threshold to be decoded and above the threshold to
> be detected. I would really appreciate comments and ideas about this.
the InterferenceHelper does not categorize packets in this way, so there
is no available API to get this power component in isolation of the
other components (such as the thermal noise component).
If I needed this quantity, I would probably create a separate tracker
(perhaps reuse another InterferenceHelper object, perhaps create a
special object) and add only those packets whose energy is found to be
between the thresholds that you indicated.
- Tom