ACK Handling

IEEE 802.15.4 has a mandatory feature for ACK's on L2 in a tight time frame. ACKs are only needed for data and command frames and not beacon or ack frames. Many transceivers implement this ACK handling as automated task in the hardware which can be enabled.

IEEE 802.15.4-2011 section 5.1.6.4 (page 44ff)

• Beacon frame must have ack request bit 0
• Ack frame must have ack request bit 0
• Broadcast frame must have ack request bit 0
• Data and MAC frames can have ack request bit 0 or 1. If set to 1 the receiving node must send an ack back.

Transceivers with hardware support for ACK handling:

• at86rf212
• at86rf212b
• at86rf230
• at86rf231
• at86rf232
• at86rf233
• atusb (at86rf231 + mcu)
• cc2420
• cc2520
• cc2531 (cc2520 + mcu)
• mrf24j40
• adf7242
• Xbee

Transceivers without hardware support for ACK handling:

• None we are aware of right now

Software Situation

RIOT:

• NETOPT_AUTOACK as setting for link layer ack's and it should be enabled by default
• If the hardware has AUTOACK enabled the ack request bit will be set for outgoing data frames. (sys/net/gnrc/application_layer/zep/gnrc_zep.c:886 as well as drivers/at86rf2xx/at86rf2xx_netdev.c:50)
• No handling for ack request for MAC command frame found (do they actually have MAC command frame support?)
• Only the at86rf2xx and kw2xrf driver seem to handle the NETOPT_AUTOACK configuration option
• From talking with a RIOt developer I got the info that it should be enabled in any case if NETOPT_AUTOACK is set

Contiki:

• If the ack_required field is set depends on the configuration options PACKETBUF_ATTR_MAC_ACK and/or PACKETBUF_ATTR_RELIABLE
• If ACKs are required is depending on the networking stack you choose and various configuration options.
• If you want to be sure that ACKs are required you can set it in your app before sending. (examples/ipv6/native-border-router/border-router-rdc.c)