LR-WPAN: TRANSCEIVER state

[charls charls]

Hi,

I would like to ask a question a bout the transceiver state, If am wrong please correct me.

The current PHY state of BUSY_RX makes a strong signal with a good value SINR to be dropped. I mean, when an interfering weak signal is in transimission(whose value of sinr>-5dB but still weak to have significant impact on packet dropping), the receiver will change to busy_RX and this will cause 

packet dropping for correct(not interfering signals) signals that would otherwise not resulted to harmful interference. I am referring to cases when the two transmitters are not within CCA radius as below 

A--------->B--------C--------->D : A and C are transimitters and B and C are receiving nodes

A and C can not hear transmissions from Each other: assume C starts transmitting  before A, and A starts transmitting when transmissions of C are in progress, the interfering signal from C to B will change the transceiver at B to busy_RX and the transmission of A will be dropped even when the interference could be less harmful(All packets that find the receiver busy_RX are dropped). Does this depict reality? 

Thank you

CJ

[Tommaso Pecorella]

Hi,

the standard does not say anything about this case. As is: it is implementation dependent.

Nevertheless, yes, this is the correct behaviour (otherwise it would had been a bug).

Again, the explanation for this is very simple, and it has to do with signal physics. Something you're not very good at, if I do remember well.

Node B must change to BUSY_RX when it hears a packet preamble above the signal threshold. It could stop the reception once it knows the packet is not directed to it.

However, in order to perform the decision, it should decode at least...

The preamble + SFD fields (that's some µs), plus the frame length (1 octet). However the destination addresses (and the PAN destination ID) are in the PSDU.

Basically to perform the decision you have to decode between 4 to 20 octets more.

Then the device may decide to stop listening to the current packet and return in a (simple) RX status.

Now, is this necessary ? Apparently no. And the answer it is just a matter of logic.

Theorem: Stopping the packet reception for frames not directed to the node is useless.

Axiom: The standard authors are not imbeciles.

Facts:

1. The Rx-stop procedure is useful in case of high collision probability and hidden terminal scenarios.
   
2. The RTS-CTS is a popular and well known technique to fight the same issue, and it is far more reliable than stopping the current Rx if the frame is not directed to the device.
3. The RTS-CTS procedure is not even optional in 802.15.4

Since RTS-CTS is more efficient than stopping the current Rx, then only one of the following case is right:

1. the theorem is wrong, and the standard authors are imbeciles (because they had to include RTS-CTS in the standard).
   
2. the theorem is right.

Since option 1 goes against an axiom, then the only possibility is that the theorem is right.

Q.E.D.

Anyway, feel free to modify the code to test it.

The only thing to remember is to keep the receiver in the BUSY-RX state for the right amount of time, i.e., enough to decode the source and destination addresses.

Cheers,

T.