Sleepy end device dynamic behavior

[Di Piazza Alain]

Hello,

I have some questions relative to the behavior of sleepy end devices.

POINT1: Suppose my SED is sending COAP request in confirmable mode.

-----------
Once my SED has sent its COAP request (Confirmable mode), its radio RX part will need need to stay ON until the COAP acknowledgement has been received.

Knowing that the default ACK_TIMEOUT is equal to 2 sec and that the MAX_RETRANSMIT is set to 4, it means that the RX part of my SED can eventually stay ON for several seconds in case, its COAP requests is not acknodged in time. It will not be able to enter in low power mode until its COAP request has been acknowledged.
#Do you agree with that ? (OK/KO)

POINT2: Suppose my SED is sending a COAP request in non-confirmable mode and in multicast.

-----------

In this case, due to MPL retransmission, the SED will transmit each COAP message twice. The SED will stay ON until all these retransmission has occurred.

These retransmissions are immediate meaning that in this case, the SED should stay ON for a very short period. 

#Do you agree with that ? (OK/KO)

POINT3: Suppose my SED has nothing special to do...
------------
The SED will wake up every ‘pool message’ in order to send a keep message. So every pool period,  the SED will first activate its TX to send a keep alive message (In this case a MAC data request). Then it will activate its RX, in order to listen to the aknlowdegment of the keep alive message. At this end, it will deactivate its TX and RX an enter in low power mode and wait for 'pool' period.

#Do you agree with that ? (OK/KO)

POINT4 : Suppose a router wants to send a message to a SED..

------------

In the wiki, it is written a "Sleepy End Device (SED) — normally disabled, wakes on occasion to poll for messages from its parent".

# How does this mechanism works ?
# If the parent send a COAP unicast confirmable request to a sleep end device, how will the SED retrieve this message and when ? 
# Will the parent detect the fact that the SED has not received its message since the SED is most of the time disabled ?

Thanks a lot for the clarifications.

[Jonathan Hui]

See responses below:

On Wed, Apr 4, 2018 at 7:09 AM, Di Piazza Alain <dipiaz...@gmail.com> wrote:

Hello,

I have some questions relative to the behavior of sleepy end devices.

POINT1: Suppose my SED is sending COAP request in confirmable mode.

-----------
Once my SED has sent its COAP request (Confirmable mode), its radio RX part will need need to stay ON until the COAP acknowledgement has been received.

Knowing that the default ACK_TIMEOUT is equal to 2 sec and that the MAX_RETRANSMIT is set to 4, it means that the RX part of my SED can eventually stay ON for several seconds in case, its COAP requests is not acknodged in time. It will not be able to enter in low power mode until its COAP request has been acknowledged.
#Do you agree with that ? (OK/KO)

The Sleepy End Device (SED) should poll for responses, allowing it to sleep most of the time.  You can temporarily set the poll period to a shorter value while waiting for a response using otLinkSetPollPeriod().

POINT2: Suppose my SED is sending a COAP request in non-confirmable mode and in multicast.

-----------

In this case, due to MPL retransmission, the SED will transmit each COAP message twice. The SED will stay ON until all these retransmission has occurred.

These retransmissions are immediate meaning that in this case, the SED should stay ON for a very short period. 

#Do you agree with that ? (OK/KO)

SEDs to not participate in in MPL retransmissions.  Thread 1.1.1 Section 5.11.2 states: "A Thread End Device MUST transmit realm-local and larger scope multicasts as IEEE 802.15.4 unicasts to its parent."

 

POINT3: Suppose my SED has nothing special to do...
------------
The SED will wake up every ‘pool message’ in order to send a keep message. So every pool period,  the SED will first activate its TX to send a keep alive message (In this case a MAC data request). Then it will activate its RX, in order to listen to the aknlowdegment of the keep alive message. At this end, it will deactivate its TX and RX an enter in low power mode and wait for 'pool' period.

#Do you agree with that ? (OK/KO)

Yes, the poll message also serves as a keep-alive with its parent.  After sending a IEEE 802.15.4 Data Request message and receiving an IEEE 802.15.4 ACK, the SED will sleep until the next data poll event.

 

POINT4 : Suppose a router wants to send a message to a SED..

------------

In the wiki, it is written a "Sleepy End Device (SED) — normally disabled, wakes on occasion to poll for messages from its parent".

# How does this mechanism works ?
# If the parent send a COAP unicast confirmable request to a sleep end device, how will the SED retrieve this message and when ? 
# Will the parent detect the fact that the SED has not received its message since the SED is most of the time disabled ?

The parent will attempt to deliver the message the next time the SED initiates a poll.

ACK Request is enabled for all unicast messages sent to the SED.  If no ACK is received, it will wait for the next data poll and try to deliver again.

--

Jonathan Hui