• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 624 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC1310: How to set carriere sense time to 5ms or above

CC1310: CMSA/CA MAC parameters for ARIB STD-T108

Slev1n
Genius 5680 points
Part Number: CC1310

Hello,

(this is a related question!!!) I have a few questions regarding the calculation of the backoff period, the carrier sense time and the following MAC variables:

/*! MAC Parameter */
/*! Min BE - Minimum Backoff Exponent */
#define CONFIG_MIN_BE   7
/*! Max BE - Maximum Backoff Exponent */
#define CONFIG_MAX_BE   7

/*! MAC MAX CSMA Backoffs */
#define CONFIG_MAC_MAX_CSMA_BACKOFFS   4
/*! macMaxFrameRetries - Maximum Frame Retries */
#define CONFIG_MAX_RETRIES   1

I do use the sensor/collector example from the TI 15.4 Stack, which is based on the IEEE 802.15.4 protocoll. Besides, the ARIB STD-T108 also refers to this IEEE standard. The goal of my question is to get to know if my carrier sense time, also described as " clear channel assessment (CCA) " in the IEEE standard, is set to 5 ms (or more).

The figure on the left demonstrates the basic process of the CMSA/CA algorithm for the unslotted non-beacon mode. I now need some help to figure out:

  • What is my "symbol period"? I use PHY ID 130 or PHY ID 129 and according to SmartRF Studio the 5kbps SL-LRM symbolrate is 20kBuad, which would lead to 50µs for the symbol period?!

  • What is my "Unit Backoff Period"? According to IEEE it is the rounded value of aTournaroundtime + aCcaTime. For SUN PHY, which I guess I am using, aTournaroundtime is described as 1ms in symbol periods (=20) and aCcaTime should be 8 symbol periods, thus the unit backoff period = 28?! PLEASE CORRECT ME IF I AM WRONG

  • With my backoffexponent set to 7 the backoff period = random(2^7 - 1)28 * 50µs = random(177800µs). Does this mean, that the backoff period, which is the delay before performing a CCA, is between 0 - 178ms? I can tell from old sniffer logs, that 178ms is approximately the time between two frame retries if no ACK was received.

  • Is the carrier sense time the sum of the backoff period + CCA or is it only the CCA?

  • Could someone provide me with an actual value for the CCA duration? Andres was already digging into this matter in the linked thread, but maybe some could help me out here.

I hope you guys can help me out.

Best wishes

Slev1n

EDIT: I checked our test equipment and I think we do not have a good enough time resolution for our sourcemeter. Maybe someone from TI could check the carrier sense time (RX active before transmission) with my settings from above?!

  • 0
    TI__Expert 3886 points

    Hi again Slev1n,

    I don’t know if I can answer all of your questions, but I did go through the standard and I also tried to track how things happen in the stack.

    1. What is my symbol period? 50us sounds reasonable.
    2. What is my unit Backoff period? Your analysis seems correct in this case.
    3. What is my delay? The value that you calculated also seems correct, although I don’t know if there is a minimum delay, or if the delay can be zero.
    4. I’m not sure about this. My understanding is that the carrier sense time is the time spent actually sensing the channel, but this might be wrong. It would make sense that it includes the backoff period.
    5. Digging in the stack I could only find that the number of symbols of CCA assessment time is 8. Which seems to fit with the aCcaTime mentioned in the Std. But I don't know if this can be interpreted as simply as saying that the CCA duration is (8 * 50us).

    I’ll try to contact an RF expert who might have some better answers.

    BR,
    Andres

  • 0 in reply to AndresM
    Genius 5680 points

    Hi Andres,

    Thanks for your fast reply.

    AndresM said:
    I’ll try to contact an RF expert who might have some better answers.

    Although your answer could already shed some light onto this matter it would be great if we could get some further support. Especially, if the backoff period has a minimum and if someone can tell us what the actual carrier sense time and CCA assessment time is.

    best wishes

    Slev1n

  • 0 in reply to Slev1n
    Genius 5680 points

    Hey Andres,

    Any news?

  • 0 in reply to Slev1n
    TI__Expert 3886 points

    Hi Slev1n,

    Sorry for the late reply. I was out-of-office until today. Unfortunately, I haven't gotten a more detailed answer yet about these specific values yet.

    BR,
    Andres

  • 0 in reply to AndresM
    Genius 5680 points

    Hi Andres,

    Thanks for the update. I will be waiting, though I hope we will get an answer soon.

    Best wishes

    Slev1n

  • 0 in reply to Slev1n
    Genius 5680 points

    Any Updates? I mean there must be some documentation on TI's side somewhere, right?

  • 0 in reply to Slev1n
    TI__Expert 3886 points

    Hi Slev1n,

    I'm sorry, but no updates for now.

    BR,
    Andres

  • 0 in reply to AndresM
    Expert 1800 points

    Hi Slev1n,

    I noticed your post and was wondering about this section because we sometimes see a similar delay in our application

    • With my backoffexponent set to 7 the backoff period = random(2^7 - 1)28 * 50µs = random(177800µs). Does this mean, that the backoff period, which is the delay before performing a CCA, is between 0 - 178ms? I can tell from old sniffer logs, that 178ms is approximately the time between two frame retries if no ACK was received.

    I don't think the CSMA backoff time should be related to the retry time for a missing ACK from the MAC layer.  When CSMA detects a busy channel, the application needs to wait a random amount of time for the channel to stop being busy, and it doesn't necessarily have any information about the other device that's occupying the channel.  So the random delay makes sense.  Compare this vs. the range of times you should have to wait for an ACK from your Collector, which should be much less random as usually the Collector should reply immediately (and the Collector doesn't have to wait on performing a CSMA check for this reply either).

    It might be a coincidence that the times are related, or it might be a bug.  For us the time between two frame retries is problematic because it lowers the throughput/bandwidth of the network, but we haven't been able to fix it.

    Best Regards,

    Arthur

  • 0 in reply to Arthur Thompson27
    Genius 5680 points

    Hi Arthuer,

    Thank you for sharing your opinion on that topic and I guess you are right that it is a coincidence. It seems I mixed up the CSMA delay after detecting an occupied channel and a transmission retry after a lacking ACK. I was digging in the forum and found an old thread by me discussing the retry delay time for non-ack messages, but the TI answer was not to elaborate.

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/890731/ccs-cc1310-sensor-collector-example-changing-message-retry-delay?tisearch=e2e-sitesearch&keymatch=CC1310%25252520retry%25252520delay#

    Besides, I did not find further similiar threads though I might have missed one. Maybe someone from TI or Andres could clearify how to control the non-ack message retry delay?

    Best wishes

    Slev1n