IEEE 802.15.4 Narrow macAckWaitDuration @unit(s) = 0.00056 s in the CSMA802154.ned

[Norberto - IT]

Hello everyone,

Can someone explain to me, why the:

macAckWaitDuration @unit(s) = 0.00056 s;  // 1+12+10+12 symbols

 

Instead of macAckWaitDuration @unit(s) = 0.000864 s;  // 20+12+10+12 symbols, as defined in the standard

 

 

Tanks in Advance.

[Daniel Pfefferkorn]

Hi Noberto,

macAckWaitDuration = aUnitBackoffPeriod + aTurnaroundTime +
phySHRDuration + ceil(6*phySymbolsPerOctet)

aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 3 - 40 Symbols [PHY-dependent]
phySymbolsPerOctet = 0.4 - 8 Symbols [PHY-dependent]

If you consider a PHY for 868�868.6 MHz O-QPSK, the values would be:
phySHRDuration = 40 Symbols [PHY-dependent]
phySymbolsPerOctet = 8 Symbols [PHY-dependent]

If you consider a PHY for 2400�2483.5 MHz O-QPSK, the values would be:
phySHRDuration = 10 Symbols [PHY-dependent]
phySymbolsPerOctet = 2 Symbols [PHY-dependent]

See Std 802.15.4-2006 p.44 & 7.4.1 MAC constants (p. 159) for more
information.

Anyhow, the smallest time could be:

aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 3 Symbols
phySymbolsPerOctet = 2.4 Symbols
--------------------------------
macAckWaitDuration = 37.4 Symbols

Which is smaller than the value that you are reporting. I would consider
this an error possibly due to a typo.

For 868�868.6 MHz O-QPSK the correct values would be:
aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 10 Symbols
phySymbolsPerOctet = 12 Symbols
--------------------------------
macAckWaitDuration = 120 Symbols or 4800 us

For 2.4 GHz the correct values would be:
aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 10 Symbols
phySymbolsPerOctet = 12 Symbols
--------------------------------
macAckWaitDuration = 54 Symbols or 864 us

I agree with you, the value is wrong and should be corrected.
Since you discovered it, it is your honor to do that. :D

Cheers,
Daniel

P.S.: Length of this answer is due to the attempt to be verbose on
purpose for reasons of understanding.

> --
> Sent from the OMNeT++ mailing list. To configure your membership,
> visit http://groups.google.com/group/omnetpp

[Daniel Pfefferkorn]

> For 868�868.6 MHz O-QPSK the correct values would be:
> aUnitBackoffPeriod = 20 Symbols
> aTurnaroundTime = 12 Symbols
> phySHRDuration = 10 Symbols
> phySymbolsPerOctet = 12 Symbols
> --------------------------------

> macAckWaitDuration = 54 Symbols or 4800 us
>

Correction:

For 868�868.6 MHz O-QPSK the correct values would be:
aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 10 Symbols
phySymbolsPerOctet = 12 Symbols
--------------------------------

macAckWaitDuration = 54 Symbols or 2160 us

[Laura Marie Feeney]

Hi Daniel and Noberto,

Thanks for the careful discussion!

However, this analysis is not correct for the CSMA802154Narrow, which
models the nonbeacon-enabled PAN.

Your formula, from section 7.4.2 of the specification, applies to
beacon-enabled PAN -- in that case, the receiver must wait until the
next slot boundary (ie up to aUnitBackoff) before transmitting the ACK.

In the non-beacon-enabled case, the receiver responds at aTurnaroundTime
(i.e. the time for the sender and receiver to both be guaranteed to have
switched from Tx to Rx and vice verse). This gives the value 192us +
352us = 544us (there's been some discussion about the "extra" 1 symbol
== 16us). Note also that in practice, the comparison should take into
account timing inaccuracy in the simulation.

This also is made clear in section 7.5.6.4.2 of the specification. You
may also want to look at the analysis and experiment in e.g. Latre et al
2006.

Laura

On 02/07/12 18:38, Daniel Pfefferkorn wrote:
>> For 868�868.6 MHz O-QPSK the correct values would be:

>> aUnitBackoffPeriod = 20 Symbols
>> aTurnaroundTime = 12 Symbols
>> phySHRDuration = 10 Symbols
>> phySymbolsPerOctet = 12 Symbols
>> --------------------------------
>> macAckWaitDuration = 54 Symbols or 4800 us
>>
>
> Correction:

> For 868�868.6 MHz O-QPSK the correct values would be:

[Daniel Pfefferkorn]

Thank you for the enlightment, Laura!

I think section 7.5.6.4.2 is the only section clearly stating the
difference of usage for non-beacon-enabled and beacon-enabled mode.

Again, thank you very much.

Kind regards,
Daniel

[Norberto Barroca]

Tanks Laura and Daniel,

I have this doubt because several “papers” used the following values

For 2.4 GHz the correct values would be:

aUnitBackoffPeriod = 20 Symbols
aTurnaroundTime = 12 Symbols
phySHRDuration = 10 Symbols
phySymbolsPerOctet = 12 Symbols
--------------------------------

macAckWaitDuration = 54 Symbols or 864 us

And as both say this is only for the beacon-enabled mode. However, sometimes for the nonbeacon-enable modeI there are also some "papers" with the same values.

So the correct value for the nonbeacon-enabled mode is:

192us + 352us = 544us (there's been some discussion about the "extra" 1 symbol == 16us).

For the beacon-enabled mode we have 54 Symbols or 864 us (for 2.4 GHz band).

Please Correct Me If I'm Wrong.

Tanks again for your help!!!

-----Mensagem original-----
De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] Em nome de Daniel Pfefferkorn
Enviada: terça-feira, 7 de Fevereiro de 2012 23:37
Para: omn...@googlegroups.com
Assunto: Re: [Omnetpp-l] IEEE 802.15.4 Narrow macAckWaitDuration @unit(s) = 0.00056 s in the CSMA802154.ned

Kind regards,
Daniel

--

[Laura Marie Feeney]

Hi Daniel,

No worries - it's always good to have people looking carefully at
simulation output!

I agree that the specification is not as clear as it should be.

Laura

>>>> For 868ￜ868.6 MHz O-QPSK the correct values would be:

>>>> aUnitBackoffPeriod = 20 Symbols
>>>> aTurnaroundTime = 12 Symbols
>>>> phySHRDuration = 10 Symbols
>>>> phySymbolsPerOctet = 12 Symbols
>>>> --------------------------------
>>>> macAckWaitDuration = 54 Symbols or 4800 us
>>>>
>>>
>>> Correction:

>>> For 868ￜ868.6 MHz O-QPSK the correct values would be:

[Laura Marie Feeney]

Hi Noberto,

Definitely, the aUnitBackoff should only be included in the ACK timeout
in the beacon enabled case.

If you are uncertain, it might be helpful for you to do the experiment!

A simple one would be to run a simulation with one host sending to
another while in transmit range and while it is out of transmit range.
Try it for both non-beacon-enabled model like MiXiM and then for a
beacon-enabled model like Castalia or InetManet. I think you'll need to
use mobility, since the host will need to be in range to associate with
the PAN in the first place - but this shouldn't be too hard to set up.
Turn on log messages or internal instrumentation and see what is
happening. (In my opinion, these kinds of simple unit tests should be
included with every module...)

Laura

[Norberto - IT]

Hi Laura,
Tanks for the advice,
But after reading the IEEE 802.15.4 standard more carefully, I agree that
definitely, the aUnitBackoff should only be included in the ACK timeout in
the beacon enabled case.
But in the future I will make some test with Castalia or InetManet as soon
as I have perform the test I will give feedback.

-----Mensagem original-----
De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] Em nome de

Laura Marie Feeney
Enviada: quinta-feira, 9 de Fevereiro de 2012 19:24
Para: omn...@googlegroups.com
Cc: Norberto Barroca

[LuisTH]

(Edited: typos on some durations)

Hi Laura,

I have checked the datasheet of two popular 2.4 GHz transceivers and they behave as you described. Thanks for pointing it out!

1) CC2420 (datasheet_here)

Figure 24 pp 42: Here, the different ACK timings is clear btw. beacon and non-beacon networks. The transceiver always wait 12 symbol periods before starting the TX of the ACK. Therefore, in case of a beacon-enable network, the strobe ACK (SACK) command, must be issued 12 symbols before of backoff slot boundary. 

Figure 25 pp 44: Radio's finite state machine. After strobe commands SRXON or STXON a calibration time (to RX, resp. TX) of 12 symbols is ensured.

I could not find hints of how long the chip does actually take to switch from RX to TX or viceversa, which I assume should be less than 12 symbol period (192 us)


2) AT86RF230 (datasheet_here)

Here the timing information comes from the "extended operation mode", a mode that includes automatic ACK generation and frame retransmission. Unfortunately, I did not find the behavior in beacon networks within extended operation mode.

Figure 7-7 pp 34: After RX a packet, the tranceiver waits 12 symbol periods before sending ACK. While waiting, the transceiver is neither in TX nor in RX (busy) state.

Figure 7-9 pp 37: After TX a packet, the tranceiver is ready to receive a packet in 32 us.

From other section of the datasheet one can see that the actual TX-to-RX and RX-to-TX times are around 33us and 17 us, respectively. But the chip enforces the turnaround time of 12 symbols (192us).

Conclusion:
in MiXiM the value of macAckWaitDuration should be based on aTurnaroundTime=12 symb (e.g. 192us @2.4GHz), as in the standard, but the actual turnaround times of the PHY layer should be set lower (owing to avoiding simulation issues like concurrent switching (end) and sending (start) in the transmitter). If one decides to switch off the switching times, the macAckWaitDuration remains the same.

Regards,
Luis.