Ack Delay in 802154 INETMANET

[Gustavo Araújo]

Hi,

I still have the ack timeout problem in csma802154 class. I have a
simple GF forwarding protocol that uses the ieee802154 as mac layer.
However, when a message is transmitted, the ack message never is
computed in time at the sender. I already realized that ack is
transmitted by receive node and sender node gets this ack message, but
sender never compute the ack in time, always a time-out event occurs.


What I have to do? Do I have to increase the "macAckWaitDuration"
parameter wich is 0.00056s? what consequences I will have if I
increase this parameter?



Thank you in advance,
Gustavo.

[Laura Marie Feeney]

Hi,

I don't use the inetmanet 802.15.4, but if you are certain that the ACK
is being received, there are a couple of things you can check.

First, ack timeout and ack transmit time are computed differently, so
the events may not be scheduled at exactly the same time. You may be
able to check this by increasing the timeout by an extremely small
amount (less than a ns).

Second, if receiving the ack msg and the ack timeout msg are scheduled
at the same time, the ack msg should have higher priority (lower
priority value) than the ack timeout msg.

Also, can you explain 560us for the ack timeout? I count 8 (preamble) +
2 (sfd) + 2 (Phy header) + 10 (5 octet PDSU) + 12 (turnaround) symbols =
544 us. Where's the extra 12 us/1 symbol coming from? processing time?

Laura

[Andreas Köpke]

BTW the standard recommends an ACK timeout of 1ms -- to allow processing
delay.

[Laura Marie Feeney]

Hi Andreas,

You're the (acknowledged :-) expert on this and I agree about processing
time, but I don't see the 1ms recommendation in the specification.

Section 7.4.2 gives

macAckWaitDuration =

aUnitBackoffPeriod + aTurnaroundTime + phySHRDuration + 6
phySymbolsPerOctet

where aUnitBackoffPeriod only matters for the beacon case and I
calculate the rest as 544us (not 560us) for 2.4GHz.

7.5.6.4.2 also says "The transmission of an acknowledgment frame in a
nonbeacon-enabled PAN or in the CFP shall commence aTurnaroundTime
symbols after the reception of the last symbol of the data or MAC
command frame".

Frames have to be separated by LIFS, which is described as allowing
processing time at the receiver, but this is shown as occurring _after_
the ACK is transmitted, i.e. Figure 68, where t_ack is delay until the
ack transmission starts and is <= aUnitBackoffPeriod + aTurnaroundTime.

To me, this somehow implies that the CRC check must take place within
aTurnaroundTime and that LIFS (or SIFS) is intended for some further
processing to pass the frame upward. I guess I could maybe believe
that, since you can accumulate the checksum as you extract the bits.
(It's not clear when decryption/MAC check is handled.) So I am (as
usual) confused...

My understanding is that the reason for keeping the ack timeout as tight
as possible is that there is a risk of misinterpreting addressless acks.

Any comment from your expertise would be great...

Laura

[Andreas Köpke]

Oh -- looks like I mixed the numbers ;)

The ACK timing is stated very precise in the standard, so it should be done
that way.

Security is somewhat difficult...

Best, Andreas