Handling of PLCP error in WiFi Phy

110 views
Skip to first unread message

wxw

unread,
Dec 4, 2015, 5:52:10 PM12/4/15
to ns-3-users
Hi, 

I am reviewing the code of YansWifiPhy. The following is my thought on the PLCP handling.

The current implementation, if PLCP is checked before receiving a packet. If PLCP fails, the whole packet fails, which is the right behavior. However, the problem is timing. Even though the packet is dropped right after the PLCP detection fails, however, not the Phy state. The PHY state would be changed in EndReceive not StartReceivePacket. This actually is not the actual behavior in practice. The major problem with it is that this prevents the receiving device to transition back to carrier sensing, which delays its transmission. 

I would like to know what you guys think about this behavior and if we should fix it.

Thanks,

Xiaowen

wxw

unread,
Dec 4, 2015, 6:06:01 PM12/4/15
to ns-3-users
Actually when I think about it, this also hinders the device's ability to receive any other packet from the PLCP fails to the MPDU end.

Tom Henderson

unread,
Dec 4, 2015, 6:30:42 PM12/4/15
to ns-3-...@googlegroups.com
On 12/04/2015 03:06 PM, wxw wrote:
> Actually when I think about it, this also hinders the device's ability
> to receive any other packet from the PLCP fails to the MPDU end.

The assumption in this model is no capture effect; once the receiver
commits to decoding a frame, even if PLCP fails to decode, it will be
committed to this frame until end of reception.

We are working on some modifications to this model to account for a PLCP
preamble sync stage, but are not working on modifications to allow the
receiver to go back to sensing if sync succeeded but PLCP header failed
to decode.

If you can point us to any documentation for how it could be better
modeled to reflect real devices, please share.

- Tom

wxw

unread,
Dec 4, 2015, 7:48:35 PM12/4/15
to ns-3-users
Hi, Tom,

I actually think that we could have a simple solution in just modified PHY a little bit to achieve the goal.

Instead of schedule EndReceive event at the start of the reception, we can schedule it after PLCP detection. Also at the start of the reception, we only set the Rx state time to be PLCP length. 

Then after PLCP detection, if PLCP is successful, we schedule the EndReceive and extend Rx state. 
If PLCP fails, we drop the packet and do a CCA on the dropped packet. 

This way we release the STA from Rx state if PLCP fails. 

BR,

Xiaowen

Tom Henderson

unread,
Dec 8, 2015, 9:00:18 AM12/8/15
to ns-3-...@googlegroups.com
On 12/04/2015 04:48 PM, wxw wrote:
> Hi, Tom,
>
> I actually think that we could have a simple solution in just
> modified PHY a little bit to achieve the goal.
>
> Instead of schedule EndReceive event at the start of the reception,
> we can schedule it after PLCP detection. Also at the start of the
> reception, we only set the Rx state time to be PLCP length.
>
> Then after PLCP detection, if PLCP is successful, we schedule the
> EndReceive and extend Rx state. If PLCP fails, we drop the packet and
> do a CCA on the dropped packet.
>
> This way we release the STA from Rx state if PLCP fails.
>
> BR,
>
> Xiaowen
>

Hi Xiowen,

I agree with your suggestion that we modify the model to allow for
strong signal capture after a PLCP header decode failure, and we'll look
into making such a modification (we are already busy with extending the
legacy error model and interference helper to provide a PLCP preamble
stage). It requires not only changes to the Phy state machine but also
the interference helper; however, it seems like we could do it without
much trouble (move the Phy to a CCA_BUSY state if PLCP header decode fails).

- Tom

Reply all
Reply to author
Forward
0 new messages