Data Response to SED after normal Thread UDP message

[ArminBreiteneder-eaton]

Hello,

Let's assume I have a Router and an SED device in a network. With the poll period the SED asks it's parent for new messages. The Acknowledge of the parent includes the bit that tells the SED if data is waiting or not.

I always imagined that this specific ACK with the additional information is always sent by the parent no matter if the message from the SED is a data request or any other message. Now I checked some occurances of this situation and saw that a normal Thread UDP message that is sent from the SED to the parent does start this action. The waiting message is sent on the next data request instead of immediately.

Is that behavior intentional or do I have to configure something in a different way to make that work? The worst thing would be that this is intentional behavior.

Thanks, BR

[abtink]

@ArminBreiteneder-eaton, let me share some background/information on this.

The parent of a Sleepy End Device (SED) can indicate that it has frames queued for the child by setting the "frame-pending" bit in the Ack frame sent to that child.

The behavior of this feature evolved with different Thread specification versions:

• In Thread 1.1 and earlier, the parent would only set the "frame-pending" bit in the Ack sent in response to a "Data Request" (poll) frame from the child.

• Thread 1.2 (and later) introduced the "Enhanced Frame Pending" mechanism. With this enhancement, the parent must set the "frame-pending" bit in the Ack not only for a "Data Request" but also in response to a regular "Data" frame sent by the child.

You can read about this in the Thread specification, Section 3.2.6.2, "Enhanced Frame Pending."

An important point is that setting the "frame-pending" bit only informs the child that a frame is queued. The child still controls when it wants to retrieve the frame. It is up to the child to send a "Data Request" (poll) to retrieve it. Here is a direct quote from the specification:

When implementing the Enhanced Frame Pending feature, rx-off-when-idle Thread Interfaces that choose to retrieve buffered data MUST explicitly begin to extract the data from the MAC Coordinator by sending the MAC Data Request command frame. A Coordinator that sets Frame Pending to '1' in the Acknowledgment frame sent in response to MAC frame types different from the MAC Data Request command frame SHALL NOT immediately send the buffered data. An rx-off-when-idle interface that receives a MAC Acknowledgment with Frame Pending set to '1' for its transmission of a MAC frame type different from the MAC Data Request command frame SHOULD NOT immediately await further received frames from the MAC Coordinator.

This is already implemented and supported by OpenThread (when built as Thread version 1.2 or later):

• The Mac implementation on an SED child checks the received Ack for an earlier Data frame transmission.
• If the parent indicates "frame-pending," the DataPollSender is notified to schedule an immediate Data Poll transmission to retrieve the queued frame.
• Here link to related code:

  openthread/src/core/mac/data_poll_sender.cpp

  Lines 325 to 364 in 6d0618f

  	#if OPENTHREAD_CONFIG_THREAD_VERSION >= OT_THREAD_VERSION_1_2
  	void DataPollSender::ProcessTxDone(const Mac::TxFrame &aFrame, const Mac::RxFrame *aAckFrame, Error aError)
  	{
  	bool sendDataPoll = false;
  	VerifyOrExit(mEnabled);
  	VerifyOrExit(Get<Mle::Mle>().GetParent().IsEnhancedKeepAliveSupported());
  	VerifyOrExit(aFrame.GetSecurityEnabled());
  	#if OPENTHREAD_CONFIG_MAC_CSL_RECEIVER_ENABLE
  	if (aFrame.mInfo.mTxInfo.mIsARetx && aFrame.HasCslIe())
  	{
  	// For retransmission frame, use a data poll to resync its parent with correct CSL phase
  	sendDataPoll = true;
  	}
  	#endif
  	if (aError == kErrorNone && aAckFrame != nullptr)
  	{
  	mPollTimeoutCounter = 0;
  	if (aAckFrame->GetFramePending())
  	{
  	sendDataPoll = true;
  	}
  	else
  	{
  	ResetKeepAliveTimer();
  	}
  	}
  	if (sendDataPoll)
  	{
  	IgnoreError(SendDataPoll());
  	}
  	exit:
  	return;
  	}
  	#endif // OPENTHREAD_CONFIG_THREAD_VERSION >= OT_THREAD_VERSION_1_2

[ArminBreiteneder-eaton]

Thank you very much for the detailed explanation. After a new check I was able to see the behavior you are explaining.