Lr-wpan: incorrect TurnArounds
A while ago I discussed with Tommaso some issues with the addition or omission of turnAround times in the transmission considerations of the Lr-Wpan module. You can see the original post here: Lr-wpan bug fixes. This issue affects both, data transmissions in both, beacon and beaconless mode.
The transmission of data packets in a beaconless mode, with a Beacon Exponent (BE) of 0 (No random backoffs delays before CCA) and no ACK flag, with a payload of 114 bytes (max payload) is calculated as follows:
1 byte = 2 sym 1 sym = 16 us (us = MicroSeconds) LIFS = 40 sym
114 bytes (data Payload) + 13 bytes (Mac header and trailer) + 6 bytes (PHY headers) = 127 bytes = 4256 us
Therefore, the interval between data packets of the same payload size should be:
4256 us (data) + 128 us (1 CCA) + 640 us (LIFS) = 5024 us
This can be seen in this figure:
Now, the problem is that the current implementation of ns-3 is adding 2 extra turnAround times (Tx->Rx and again Rx-Tx) because PHY returns immediately to RX_ON after each successfully transmitted packet. It took some time to put an example together but , according to my tests using an NXP JN5169, the transceiver seems to remain TX_On when multiple data packets are queued.
As in the previous figure, I measured the interval between MCPS-data.confirms. As previously mentioned, this value should be equal to 5024 us, however, in my experiments sending 4 packets, I obtained interval values that were around 50us over this quantity.
Likewise, I tested the interval time between MCPS-DATA.indication (interval reception of messages in the Coordinator) with similar results:
I assume that that extra 50us is MAC overhead since I am actually taking this values on LAYER 3 ( in JN5169, There is no way to directly take the times directly in the MAC that I am aware of).
Regardless, there is no way there is an extra TurnAround (192us) even less 2 TurnArounds between successful data transmissions.
In conclusion, ns-3 LR-WPAN MAC should not make the PHY go back to RX_ON after a successful transmission if there are still packets in the TX queue.
Please let me know your thoughts about this. My apologies if there is something wrong, documentation is limited and cryptic.
I attached my NXP JN5169 experiment, Feel free to ask, or point any mistakes. BeyondStudio is required to load the bin files to the chip.