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

Andreas Weigel andreas.weigel at tuhh.de
Fri Oct 16 12:19:23 CEST 2015


Hi Thomas,

> Taken from your description below, the main problem is that the 
> transceiver drops
> any packets, right?

as soon as the the transceiver enters TX_ARET, it will not receive any 
incoming packets (I guess this is due to having only one buffer 
available for TX and RX, and the requirement that the data is present in 
the buffer before entering TX_ARET) and I do not know any possibility to 
change this*.

A --> B --> C

During the automated backoff, the receiver is so to say "deaf". In a 
multihop scenario as above, when a node has to transmit several frames 
along the same path (e.g., because a larger datagram is fragmented by 
6LoWPAN, as in my case), you repeatedly get a situation where B is 
already trying to forward to C, while A is trying to send to B its next 
fragment. But B cannot hear what A is sending as long as it is in its 
own backoff phase. Factoring in C, which also tries to access the 
channel, the probability for A to finally give up after seven retries, 
is highly increased.

Mean thing about this is, that, depending on the traffic scenario (I 
used really extremely large datagrams of 1200 bytes, which caused 20% 
PRR (extended operating mode) vs. 97% PRR (software MAC)), the effect 
will be from minor to dramatic, but the probability for additional 
retries will certainly always increase.

> Does IEEE802.15.4 specify anything on this? 

AFAIK, 802.15.4 does not specify anything about the capability of a 
sender to receive during it\s backoff phase, but I'm quite sure that it 
does not forbid it in any way.

Regards,
Andreas

*if you find any method I have overlooked in the datasheet, please let 
me know :)

On 10/15/2015 09:43 PM, Thomas Eichinger wrote:
> Hi Andreas,
>
> thank you very much to point us to your work. I didn't find time yet 
> to read it
> but will do for sure. From what you shared with us by now I think this 
> are very
> useful informations we definitely should consider for our driver.
>
> I have to admit when I once started it, the promises extended 
> operating mode made
> were too auspicious to not use it, and I never came to run actual 
> multi hop tests
> on it yet.
>
> At least with the possibility of disabling CSMA-CA chances are we 
> don't have to
> rewrite it again.
>
> Taken from your description below, the main problem is that the 
> transceiver drops
> any packets, right? Does IEEE802.15.4 specify anything on this?
>
> Anyhow, I will try to get your article tomorrow and thanks again for 
> sharing this
> with us.
>
> Best,
> Thomas
>
> On 15 Oct 2015, at 14:38 CEST(+0200), Andreas Weigel wrote:
>
>> 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
>>
>>
>> -- 
>> ________________________________________________________________________
>> 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
>> ________________________________________________________________________
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
> _______________________________________________
> 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