CCAModelThreshold and EnergyDetectionThreshold

1,479 views
Skip to first unread message

Rafael Araújo da Silva

unread,
Aug 31, 2015, 2:22:53 PM8/31/15
to ns-3-users

Hi! I'm a bit confused about CCAModelThreshold and EnergyDetectionThreshold attributes in YansWifiPhyHelper.


Carrier Sense is the ability of the receiver to detect and decode an incoming Wi-Fi signal. And Energy Detection is the ability of the receiver to detect non Wi-Fi energy level present on the current channel (like Wi-Fi transmissions that can no longer be decoded). I suppose Carrier Sense threshold is defined by CCAModelThreshold parameter in NS3. Is it Right?


So, I have started a flow from node A to B which distance and propagation model result in a received power between CS and ED thresholds. I expect all packets dropped, but NS3 has delivered all in my simulation. The same occurs in a less distance with received power over CS threshold. But when received power is less than ED threshold, all packets are dropped.


Debugging, I have found something like this: if rxPower > EnergyDetectionThreshold {receive} else {drop} in YansWifiPhy::StartReceivePlcp.


Is EnergyDetectionThreshold the right parameter to determine the discard? Should not be CCAModelThreshold? Why? Can someone help me with this?


Regards,

Rafael

Yiannis

unread,
Sep 2, 2015, 5:26:22 AM9/2/15
to ns-3-users
Hi Rafael,

Ed stands for the Energy Detection. If the received power of a signal is above that threshold then the packet can be decoded (probably successfully), otherwise
it's been dropped. CCAModelThreshold accounts for the threshold when the node senses the wireless channel. If the energy detected for a DIFS period is lower than
the CCA threshold the channel is IDLE, otherwise is busy.

Yiannis

Rafael Araújo da Silva

unread,
Sep 3, 2015, 10:03:54 AM9/3/15
to ns-3-users

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.


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?


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.


Regards,


Rafael

Tom Henderson

unread,
Sep 3, 2015, 1:56:14 PM9/3/15
to ns-3-...@googlegroups.com
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

Rafael Araújo da Silva

unread,
Sep 4, 2015, 9:12:58 AM9/4/15
to ns-3-users
Many thanks for your insightful answer, Tom.

Adeel

unread,
Feb 2, 2017, 2:39:21 AM2/2/17
to ns-3-users
 Hi Tom !
   After reading your explanation I become a bit confused :-p
   Why you think that ED should be greater than CCA check ?
    ED is the threshold of energy that your system would decide whether
    this message is decodable or not. I think it should be lesser than CCA
    check to prevent collision and enhance CSMA/CA function. Of course it will
    cause to increase a backoff timer but it makes the network more robust.
    Well, however, this is my opinion :-)

   Cheers,  Adeel

Tom Henderson

unread,
Feb 2, 2017, 12:42:32 PM2/2/17
to ns-3-...@googlegroups.com
On 02/01/2017 11:39 PM, Adeel wrote:
> Hi Tom !
> After reading your explanation I become a bit confused :-p
> Why you think that ED should be greater than CCA check ?
> ED is the threshold of energy that your system would decide whether
> this message is decodable or not.

CCA is a function of ED threshold (detection of non-wifi signals),
carrier sense threshold (threshold for decoding the wifi preamble) and
virtual carrier sense (reading the NAV). ED threshold is typically
higher than the CS threshold.

- Tom

Reply all
Reply to author
Forward
0 new messages