Putting non-sleepy MTD to sleep

[pieter....@basalte.be]

Hi,

Sorry for the confusing title, but you're reading this, so it got your attention :)

If a device, when active, has its antenna on for receiving all the time, it shouldn't be considered a SED, right?

For that reason, my device has mRxOnWhenIdle set to true (non-sleepy), so it receives all messages right away, and the parent does not need to buffer these.

After some time of inactivity, I do want to put that same device to sleep to save battery, and wake up on interaction with the device itself. During this time all messages may be dropped.

Some things I'd like to clarify:

1. Is my assumption correct about not being a sleepy end device?

2. Can an MTD sleep for a long time and rapidly connect to a parent on wake up? Does the child timeout setting affect this?

3. Should my MTD dynamically switch modes (sleepy/non-sleepy) in order to support the described use-case?

4. Should the MTD perform some "going to sleep"/detach notification steps, or can it simply cut the power?

Thanks in advance,

Pieter

[Abtin Keshavarzian]

Hi Pieter,

Short answer is no! Non-sleepy cannot (and should not) sleep. But we can change the MLE "mode" on device to switch it to "not be non-sleepy" and have it sleep (but then technically it is no longer non-sleepy... :)....)

1) Is my assumption correct about not being a sleepy end device?

Yes. If `mRxOnWhenIdle` is `true` then radio receiver would be always on (on idle mode when not sending) and device is not sleepy.

2) Can an MTD sleep for a long time and rapidly connect to a parent on wake up? Does the child timeout setting affect this?

A sleepy device that is attached to a parent, can awaken anytime and immediately start sending data to its parent (no need to sync or re-establish any connection with its parent). 

Child timeout is simply a promise by the child that it will talk to its parent (exchange data poll, or some data frame to indicate that it's still there) within the timeout interval (it may communicate more often but at min within the timeout interval). If the parent does not hear from the child within the timeout interval, it can kick it out its child table (no longer consider it a child). It is up to the child to select the timeout interval. Child will let the parent know during attach what timeout value it wants to use. The child can also change the timeout interval later and then it needs to sync the new value with parent through MLE "child update" mechasnim. 

3) Should my MTD dynamically switch modes (sleepy/non-sleepy) in order to support the described use-case?

It is certainly possible to switch mode during run-time. But I would say in your use-case (sleep often and awaken on some events) it probably make sense to have device operate as sleepy. Child can always awaken and send info to parent.  

4) Should the MTD perform some "going to sleep"/detach notification steps, or can it simply cut the power?

Just to clarify something, in a sleepy device the radio is put in low-power (sleep) mode but it is expected the info stored in RAM (on SED's MCU) to be retained. 

If by "cut the power" you mean fully shut down the device (i.e. do not retain RAM variables) then device is powered off (it is not technically attached to network or considered a sleepy end-device anymore). In such a case, upon power up the device needs to attach (reattach) to the same (or possibly new) parent.

Hope this helps,

Abtin.

[pieter....@basalte.be]

Thank you, Abtin for the fast response!

I actually wasn't aware of the difference between sleep/power off, it does make a lot of sense now.

We currently are unable to retain any info stored in RAM, so the device needs to reattach on wake-up as you said. A few follow-up questions:

1. Is there some sort of penalty of not being able to sleep, as opposed to a full power-off, besides hardware initialisation?

2. If we would be able to implement a sleep in a co-processor design, can the RCP be fully powered off?

Thanks,

Pieter

[Abtin Keshavarzian]

1) Is there some sort of penalty of not being able to sleep, as opposed to a full power-off, besides hardware initialisation?

Upon power-on the device/child needs to re-attach to Thread network before it can send anything to other devices. This  will require multiple message exchanges (at min two MLE exchanges) and period of having the radio on (rx mode) which can be rather energy consuming.

The child typically remembers its previous parent in the non-volatile settings and upon restart it tries to first attach to the same parent (using quick re-attach MLE Child Update mechanism). But if it is timed out (kicked out of the parent child table), the child needs to go through full attach process during which child would send multiple MLE "Parent Request" followed listening for ~2 seconds to receive MLE "Parent Responses" from all potential parents to then choose best parent and then try to attach it (which require at minimum two more MLE message exchanges). 

2)  If we would be able to implement a sleep in a co-processor design, can the RCP be fully powered off?

Short answer is no, RCP should also retain memory/RAM. It may be technically possible to keep track of this on host side and re-init the RCP every time (but I think it would require a lot of changes in the code and its design). Also I am not sure how practical this model is since the host MCU is typically more capable than RCP's MCU and if we assume host is retaining RAM, it will probably consume much more power than having the RCP's MCU doing the same.