Some inquires regarding CSL feature

[Ahmed Ismail]

Dear Openthread Team,

 

I need to confirm my understanding of the following points:

1-            Should the radio driver update “mCslPresent” as I didn’t notice any usage to it in the latest openthread version? if yes when should the platform update it?

2-            I understand that only one TX request at a specific time will be sent to the radio driver and the openthread waits for the TXdone to send another TX request, is my understanding correct? Or Can we have multiple TX requests at a specific time? If yes, Are they ordered in time?

3-            I understand that CSMA is disabled and frame retrials are set to zero in case of TX at a specific time, Is my understanding correct?

4-            I understand that CSL receive can receive data from its parent only. Is there any use case where the CSL receiver can receive frames from devices other than its parent device?

 

Also, as Our radio can coexist with the BLE5.2, we have the following two concerns, could you please advise on how they can be handled?

5-            In the case of  CSL receiver, the first CSL sample time is determined only based on the current time when the thread CSL receiver starts. This sample time can conflict with other radio activities the controller has. So How can we inform openthread about the suitable time for sampling the channel?

6-            BLE clock accuracy can be 500ppm, this value can’t fit in the uint8t variable that openthread use. Should the variable be uint16_t or can we set it 255 for all values greater than 255ppm

 

Thanks,

Ahmed Ismail

--

Ahmed Ismail

Embedded Software Engineer

Si-Vision LLC

Square 1142, Al Ezaei Salah Zaki St.,

Sheraton Heliopolis,

Cairo, 11361 EGYPT Mob. +(2)01142404427 www.si-vision.com

The information contained in this message is privileged, confidential or otherwise protected from use and disclosure. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying or dissemination of this message or the taking of any action in reliance on its contents, or other use is strictly prohibited.  If you received this message in error, please notify us immediately by replying to the message and deleting it from your computer.  Thank you.

Si-Vision, LLC.

[Li Cao]

Hi Ahmed,

-            Should the radio driver update “mCslPresent” as I didn’t notice any usage to it in the latest openthread version? if yes when should the platform update it?

I assume you mean the field in `otRadioFrame.mTxInfo`. Looks like there are some mistakes in the code. We'll fix it soon. This field should be set by OpenThread core, not the radio driver.

-            I understand that only one TX request at a specific time will be sent to the radio driver and the openthread waits for the TXdone to send another TX request, is my understanding correct? Or Can we have multiple TX requests at a specific time? If yes, Are they ordered in time?

In radio driver, there will be only one TX request at a specific time. OpenThread may schedule multiple CSL TX requests. When the TX time of one request is coming soon, OpenThread sends the request to radio driver. And before the TX was completed, no other TX/RX operations can be processed. OpenThread tries to make this blocking time very short.

-            I understand that CSMA is disabled and frame retrials are set to zero in case of TX at a specific time, Is my understanding correct?

Yes, CSMA is disabled when doing CSL TX.

-            I understand that CSL receive can receive data from its parent only. Is there any use case where the CSL receiver can receive frames from devices other than its parent device?

As I know, CSL receiver only receive frames from its parent. I think this is the same for all End Devices (including SED) in OpenThread.

-            In the case of  CSL receiver, the first CSL sample time is determined only based on the current time when the thread CSL receiver starts. This sample time can conflict with other radio activities the controller has. So How can we inform openthread about the suitable time for sampling the channel?

Not quite sure on this. Is your BLE stack and Thread on the same chip?

-            BLE clock accuracy can be 500ppm, this value can’t fit in the uint8t variable that openthread use. Should the variable be uint16_t or can we set it 255 for all values greater than 255ppm

uint8_t is used because in CSL Accuracy TLV specified in Thread specification, the value field is only one byte. Why do we set it to BLE clock accuracy here? Does Thread share the clock source with BLE?

Best regard,

Li

[Ahmed Ismail]

Hi Li,

Thank you for your reply. we noticed that  when a microsecond value is reported to Openthread it uses the "uint64_t" range. but when a microsecond time is given to the radio driver from Openthread, it uses the "uint32_t" range. for example, uint64_t is used in return value of otPlatRadioGetNow() in radio.h and timestamp parameter in otRadioFrame.mRxInfo while uint32_t is used in aStart parameter in otPlatRadioReceiveAt() in radio.h, aCslSampleTime parameter in otPlatRadioUpdateCslSampleTime() in radio.h, and mTxDelayBaseTime parameter in otRadioFrame.mTxInfo.

I have a concern regarding using uint32_t for those parameters as the uint32_t microsecond value will overflow every  71 minutes (Full range of uint32_t in microsecond) which is a too small time to overflow. and I think that the uint64_t should be used for those parameters. please let me know If I am missing something?

Thanks,

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/7416f242-ba90-4c6f-84c3-efaf4b893028n%40googlegroups.com.

--

Ahmed Ismail

Embedded Software Engineer

Si-Vision LLC

Square 1142, Al Ezaei Salah Zaki St.,

Sheraton Heliopolis,

Cairo, 11361 EGYPT Mob. +(2)01142404427 www.si-vision.com

[Jonathan Hui]

71 minutes should be more than enough for CSL. We expect CSL periods to be on the order of seconds. The radio driver implementation should make sure to handle rollovers properly.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAG%3Dep%3DED0rdzqjNy-KyU8gWSu1obG_CxD3eXCipDo9kpTRJSRA%40mail.gmail.com.

[Ahmed Ismail]

Hi  Jonathan And  Li, 

Thank you for the clarification and sorry for the late response. We worked on handling it in our radio driver in it seems to work.

regarding -

-            I understand that only one TX request at a specific time will be sent to the radio driver and the openthread waits for the TXdone to send another TX request, is my understanding correct? Or Can we have multiple TX requests at a specific time? If yes, Are they ordered in time?

In radio driver, there will be only one TX request at a specific time. OpenThread may schedule multiple CSL TX requests. When the TX time of one request is coming soon, OpenThread sends the request to radio driver. And before the TX was completed, no other TX/RX operations can be processed. OpenThread tries to make this blocking time very short.

I noticed the blocking time is very short and depends on OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US  in most cases but  I  have an incident when the request time is 500ms ahead of the current time.  this happens when the CSL channel is created between the parent and SSED with CSL period = 500ms , then the thread is stopped in both devices then the thread is started in both devices. the parent device is set the delay in Tx request. the sequence of commands to have this  issue is below :

SSED  --> csl period 3125

SSED  --> csl timeout 100

FTD   --> ifconfig up

FTD   --> thread start

FTD   --> state   --> leader

SSED  --> ifconfig up

SSED  --> thread start

SSED  --> state   --> child 

FTD   --> ping     --> ping is ack

SSED  --> thread stop

FTD   --> thread stop

FTD   --> ifconfig up

FTD   --> thread start

FTD   --> state   --> leader

SSED  --> ifconfig up

SSED  --> thread start

I believe that the request is sent too early to the radio driver in this case. and it is an issue in csl_tx_scheduler. am I missing something?
also, Should the radio driver stops reception upon receiving a TX at a specific time even if RX when on idle is enabled and the request is too far?

thanks,

[Ahmed Ismail]

Dear All,

Do you have any intuition about this issue?

thanks,

Ahmed Ismail

[Li Cao]

Hi Ahmed,

Sorry for the late response.

- I  have an incident when the request time is 500ms ahead of the current time. 

Do you mean you have the issue when setting OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US to 500? Note that the unit of this us(microseconds), not ms(milliseconds). OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US is a small preserved time for SubMac to do the actual transmission. So after CslTxScheduler requests Mac to do CSL transmission, Mac will start a timer. The timer is not accurate (its accuracy is ms) and will fire at a time that is a little ahead of the target transmission time. This is to ensure when the CSL request comes to SubMac, SubMac still has some time to process the transmission. The default value for it is 2000us (2ms). Do you mean you set it to 500us(0.5ms) or 500000us(500ms)?

- the parent device is set the delay in Tx request

What does this mean?

- I believe that the request is sent too early to the radio driver in this case. and it is an issue in csl_tx_scheduler.

csl_tx_scheduler does request Mac earlier, and Mac requests SubMac a little earlier. And finally SubMac will make sure to transmit at a precise time.

- Should the radio driver stops reception upon receiving a TX at a specific time even if RX when on idle is enabled and the request is too far?

If RX-on-when-Idle is enabled, then the radio driver should keep receiving. But how could RX-on-when-Idle be enabled for SSED? SSED should be Rx-off-when-Idle by definition.

I'm not sure if I understand your issue correctly. So do you mean: after you stop both devices and start both, SSED cannot attach successfully?

Best regards,

Li

[Li Cao]

Supplement for my description:

- csl_tx_scheduler does request Mac earlier, and Mac requests SubMac a little earlier. And finally SubMac will make sure to transmit at a precise time.

So I mean, when csl_tx_scheduler requests Mac, there could be a long time from now to the target transmission time, a few seconds or a few milliseconds.

And when Mac calls SubMac to do the transmission, there should be still a short time from now to the target transmission time, one or two miliiseconds, or a few microseconds (less than OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US)

[Ahmed Ismail]

Hi Li,

thank you for the reply. let me clarify the issue.

- I  have an incident when the request time is 500ms ahead of the current time. 

Do you mean you have the issue when setting OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US to 500? Note that the unit of this us(microseconds), not ms(milliseconds). OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US is a small preserved time for SubMac to do the actual transmission. So after CslTxScheduler requests Mac to do CSL transmission, Mac will start a timer. The timer is not accurate (its accuracy is ms) and will fire at a time that is a little ahead of the target transmission time. This is to ensure when the CSL request comes to SubMac, SubMac still has some time to process the transmission. The default value for it is 2000us (2ms). Do you mean you set it to 500us(0.5ms) or 500000us(500ms)?

--> I Know that OPENTHREAD_CONFIG_MAC_CSL_REQUEST_AHEAD_US is in microseconds.. we the the default value  which is 2000us = 2ms. but  when we recive the TX request at our radion from Submac, we noticed that the request time (base + delay ) is still far in the future comparing for the current. the difference is about 500ms which the is tha same the used CSL period. for example : delay = 400000us , time base = 111100000us where OtPlatRadioTransmit is called at 111000000us. for add more calification, in normal senairos execpt the mentioned senario, the diffenrece between the current time and the  time in TX frame given at OtPlatRadioTransmit is less than 2000us as expected.

- the parent device is set the delay in Tx request

What does this mean?

I mean Tx delay and timebase set in Txframe for CSL transmitter while OtPlatRadioTransmit is called .

- Should the radio driver stops reception upon receiving a TX at a specific time even if RX when on idle is enabled and the request is too far?

If RX-on-when-Idle is enabled, then the radio driver should keep receiving. But how could RX-on-when-Idle be enabled for SSED? SSED should be Rx-off-when-Idle by definition.

I mean when the CSL Transmitter, which is a FTD so RX-on-when-idle is enabled, send TX at request to the radio driver and radio driver see there is an enough time to start reception. should the redio driver start the reception and when the TX time comes , send the frame. Or Openthread excepts no frame in this period and for that reason, radio driver had not enable it receiver

I would really appericate your fast response.

thanks in advace,

Ahmed Ismail

You received this message because you are subscribed to a topic in the Google Groups "openthread-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openthread-users/iV6C1zfLLZg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/2fef7055-f706-4550-adbb-439bd5bff984n%40googlegroups.com.

[Li Cao]

Hi Ahmed, 

Thanks for the clarification. 

I'd like to more about your case. Is your CSL transmitter a ot-cli-ftd or posix daemon (using RCP mode)?

- when we recive the TX request at our radion from Submac, we noticed that the request time (base + delay ) is still far in the future comparing for the current. the difference is about 500ms which the is tha same the used CSL period. for example : delay = 400000us , time base = 111100000us where OtPlatRadioTransmit is called at 111000000us.

The base and delay you mentioned is the value here, right?: sub_mac.cpp:383

```

#if !OPENTHREAD_MTD && OPENTHREAD_CONFIG_MAC_CSL_TRANSMITTER_ENABLE

    if (mTransmitFrame.mInfo.mTxInfo.mTxDelay != 0)

    {

        SetState(kStateCslTransmit);

        if (ShouldHandleTransmitTargetTime())

        {

            if (Time(static_cast<uint32_t>(otPlatRadioGetNow(&GetInstance()))) <

                Time(mTransmitFrame.mInfo.mTxInfo.mTxDelayBaseTime) + mTransmitFrame.mInfo.mTxInfo.mTxDelay -

                    kCcaSampleInterval)

            {   // Branch 1

                mTimer.StartAt(Time(mTransmitFrame.mInfo.mTxInfo.mTxDelayBaseTime) - kCcaSampleInterval,

                               mTransmitFrame.mInfo.mTxInfo.mTxDelay);

            }

            else // Transmit without delay

            {   // Branch 2

                BeginTransmit();

            }

        }

        else

        {   // Branch 3

            BeginTransmit();

        }

        ExitNow();

    }

#endif // !OPENTHREAD_MTD && OPENTHREAD_CONFIG_MAC_CSL_TRANSMITTER_ENABLE

```

You may see the 'Branch' I added into the above code. Could you verify which branch does your code go to? I guess it should be branch 1. Then a timer starts, and it should fire at the time `base + delay`, and then otPlatRadioTransmit is called. When the timer fires, a handler is called sub_mac.cpp:695:

```

    case kStateCslTransmit:

        BeginTransmit();

        break;

```

Could you verify the timestamp when code goes here? 

- send TX at request to the radio driver and radio driver see there is an enough time to start reception. should the redio driver start the reception and when the TX time comes , send the frame. Or Openthread excepts no frame in this period and for that reason, radio driver had not enable it receiver

Good question. Actually it doesn't Does your radio driver supports something like `transmit_at`?

• If it does, then in the above code, it will be Branch 3. So when the request arrives `SubMac`, there will be still a little time (a few microseconds). But `SubMac` directly passes it to the radio driver. And the radio driver will handle the delay (transmit at the precise time). Note that before the precise time comes, the radio driver should keep receiving. (But I think it doesn't matter, i.e., after we call transmit_at at radio driver, the radio driver directly stops receiving. It's ok since after the request arrives SubMac, the time to send won't be far from now)
• If it doesn't, then the code goes to Branch 1. And SubMac waits to the precise CSL time and call radio driver to send immediately. In this case I think we don't need to consider this issue. right?

Best regards,

Li

[Ahmed Ismail]

Dear Li,

Thank you for your prompt response. Our radio supports Transmit At capability. So it should never go to branch  1.

Regards,

Ahmed Ismail

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/bfec1715-0795-4d51-84ca-5b145f39443en%40googlegroups.com.

[Li Cao]

Hi Ahmed,

That's great. Also make sure OPENTHREAD_CONFIG_MAC_SOFTWARE_TX_TIMING_ENABLE is enabled on your platform. For the issue you mentioned, I think you can debug that by add logs printing timestamp at branch 2. And see what time is it at that moment.

Best regards,

Li

[Ahmed Ismail]

Dear Li,

the OPENTHREAD_CONFIG_MAC_SOFTWARE_TX_TIMING_ENABLE  is set to 1. kindly check the image below for the call stack when the issue happens.

I wondered that PerformNextOperation is called from the below path while the CSL receiver didn't send the syncrionization frame yet ( frame with CSL heaher IE). should the pending data is removed when the thread is stoped in both devices ?

#if OPENTHREAD_FTD && OPENTHREAD_CONFIG_MAC_CSL_TRANSMITTER_ENABLE
        else if (mPendingTransmitDataCsl)
        {
            PerformNextOperation();
        }
#endif

        break; 

Also, here is the value of some important variables 

aFrame->mInfo.mTxInfo.mTxDelay = 560960
aFrame->mInfo.mTxInfo.mTxDelayBaseTime = 135300038

Current Radio time is  = 135359187us

A note that may be useful, the issue happened  in CSL transmitter while the CSL receiver is trying to attach again to the parent before sending the frame with CSL header IE to start syncronization again. If we send reset to both devices before repeating the sequence of commands, the issue disappears

please let me know to need to dump and other variables or traces to get more insight about the issue

Regards,

Ahmed Ismail

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/8a408a2f-78a3-44e8-8a75-32c5b3591decn%40googlegroups.com.

[Li Cao]

Hi Ahmed,

It looks like the child's CSL state (recorded by parent) isn't cleared after a restart. Do you know what message is the parent sending (using the unexpected CSL)?  Is it a Child Id Response? 

It is expected that the parent maintains its children's state (including buffered messages) even after reboot so that a re-attach goes better. While I think the parent should clear the child's CSL state after restarting. I'd like to have a discussion about this.

However I'm still not sure why the radio time is far away from `mTxDelay` and `mTxDelayBaseTime`. I noticed from your call stack that your OpenThread version seems a little old. (The line numbers displayed didn't match the recent source file) Could you update to the latest OT version (05fd1deb or after) and try again? It the problem still exists, could you record `mTxDelay`,  `mTxDelayBaseTime` and their place in code?

Best regards,

Li