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

Andreas Weigel andreas.weigel at tuhh.de
Thu Oct 15 14:38:29 CEST 2015

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.


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

  Hamburg University of Technology                andreas.weigel at tuhh.de
  Institute of Telematics (E-17)               Tel.: (+49) 40 42878-3746
  Am Schwarzenbergcampus 3                     Fax:  (+49) 40 42878-2581
  21073 Hamburg, Germany       http://www.ti5.tu-harburg.de/staff/weigel

More information about the devel mailing list