[riot-devel] at86rf2xx radio driver -- potential severe performance issues for multi-hop communication

Daniel Krebs mail at daniel-krebs.net
Thu Oct 15 15:05:41 CEST 2015

Hi Andreas, hi Alexander,

I'm implementing a new MAC layer [1] for RIOT at the moment. It's 
inspired by TinyOS LPL and ContikiMAC, but not compatible (at least not 
yet). I'm developing against our at86rf2xx driver as a reference. You 
can use it afaict the same as if it were using Basic Mode by disabling 
NETOPT_AUTOACK, so no need to rewrite the driver. Concerning CSMA you 
can also easily disable CSMA/CA via NETOPT_CSMA if you wish.

I also kind of implemented my own ACKs (called wakeup request - WR) that 
will be sent with CSMA/CA enabled, but without automatic resending 
(CSMA_RETRIES = 0). On the other hand I send the payload using AUTOACK 
so that I can tell if it really arrived at the destination. I couldn't 
test it on a bigger testbed yet, let alone multi-hop, but I can not yet 
imagine that performance would suffer that much. Still have to read your 
article though.


[1] https://github.com/RIOT-OS/RIOT/pull/3730

Am 15.10.2015 um 14:38 schrieb Andreas Weigel:
> Hi again,
> indeed this should solve the issue -- I have to admit, that I hadn't 
> considered this possibility for our driver, because I adapted the 
> TinyOS MAC layer (using the basic operating mode) and had everything 
> there already, including a handling of the ACKs in software, which 
> works reasonably well.
> You will obviously still have to implement the CSMA-CA mechanism then 
> if you need it. Is there already usable (for the at86rf2xx) code 
> available for a CSMA-CA in Riot? Then probably combining it with the 
> existing driver (with deactivated CSMA-CA) would be a good solution.
> Regards,
> Andreas
> On 10/15/2015 02:13 PM, Alexander Aring wrote:
>> Hi,
>> On Thu, Oct 15, 2015 at 01:57:03PM +0200, Andreas Weigel wrote:
>>> Hi everyone,
>>> I've recently executed some experiments on the performance of Atmel's
>>> extended operating mode on the ATmega256RFR2 (which afaik is 
>>> basically the
>>> same as the AT82RF2xx transceivers) in multihop collection traffic
>>> scenarios, with unslotted CSMA/CA. For those, we used our own 
>>> framework for
>>> WSNs (CometOS). Result is, that the extended operating mode can 
>>> severely
>>> impact performance (in terms of PRR) in the presence of large 
>>> fragmented
>>> datagrams sent over 6LoWPAN. However, I expect that there will be an 
>>> impact
>>> in any traffic scenario with "enough" traffic to get some node's queue
>>> filled to some extent (resulting in repeated transmissions towards 
>>> the same
>>> node).
>>> Problem is the property of the TX_ARET mode to discard any incoming
>>> transmissions during the backoff phase of the CSMA mechanism. This 
>>> leads to
>>> a large number of lost frames on longer paths (4 hops are enough to 
>>> produce
>>> a large number of losses), even with rather high backoff exponents 
>>> and the
>>> maximum number of retries. This problem caused me to reimplement our 
>>> mac
>>> driver for the ATmega256RFR2 using the basic operating mode.
>>> As far as I can see, the at86rf2xx driver in the riot repo uses the 
>>> same
>>> extended operating mode and therefore will very likely have the very 
>>> same
>>> weakness. If the time is available, it would probably be a good idea to
>>> change the driver to use the basic operating mode or alternatively 
>>> include a
>>> note for users explaining the impact of the extended operating mode 
>>> for said
>>> traffic scenarios. The frame solely caused by the extended operating 
>>> mode
>>> can render results of experiments virtually useless (speaking from 
>>> my own,
>>> sad experience ;-/  )
>> I am not a riot-dev but did you try to turn off CSMA-CA handling?
>> You can do that and I think all (except at86rf230) supports it by
>> setting MAX_CSMA_RETRIES to 7 which means no CSMA-CA handling.
>> I would _not_ use TX_ON mode only, because in this mode the ack
>> request bit in 802.15.4 MAC will be ignored always and sometimes you
>> need to the result of tx trac status if ACK was received or not. (like
>> in possible mlme-ops)
>> TX_ARET_ON will automatic wait for an ACK if ack request bit is set and
>> not if it isn't set.
>> Possible solution (maybe also in linux, because I am do a lot of
>> 802.15.4 linux stuff) would be to insert a no CSMA-CA setting which
>> performs no CSMA-CA handling, but still supports ack handling stuff 
>> then.
>> I was thinking about that already about something like that (in 
>> linux) for
>> such case, because several transceivers supports for disable CSMA-CA 
>> handling.
>> - Alex
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list