net: openthread: support WC and WED

[ankuns]

This PR adds support code for new roles Wake-Up Coordinator and Wake-Up End Device developed in OpenThread.
Related Thread Specification changes named collectively as Thread-In-Mobile (SPEC-1267).

The features require additional Information Elements (OpenThread-specific) to be sent, what's covered by the SPEC-1267.
The driver supporting the new feature CST (Coordinated Sampled Transmitting) has the capability IEE802154_OPENTHREAD_HW_CST which is OpenThread's extension to a ieee802154 driver. This capability allows to configure CST period and CST expected transmission time point.
No driver has the duty to support the capability.

The support for IEE802154_OPENTHREAD_HW_CST capability is added to the ieee802154_nrf5 driver.

The new Kconfig options OPENTHREAD_WAKEUP_COORDINATOR and OPENTHREAD_WAKEUP_END_DEVICE are added to configure the OpenThread. When OPENTHREAD_WAKEUP_COORDINATOR is enabled it enables the IEE802154_OPENTHREAD_HW_CST within the ieee802154_nrf5 driver by default.

Refs:
7ec824602518060a19b7ba851435f043b5ca8a8d
f59ec0e8af9f1c373752bdf1324befb27de1f493
a3dcf1c536387a0f9ba662436ce37617cf9cedf7

[ankuns]

Hi @fgrandel could you please have a look on this draft PR? I would like to ask you if this proposal is compliant with adopted rules, especially #61227 .

I think only the commit with title net: openthread: add capability IEEE802154_OPENTHREAD_HW_CST is relevant to these rules, remaining are specific just to ieee802154_nrf5 driver and openthread integration.

The new introduced capability IEEE802154_OPENTHREAD_HW_CST is specific to OpenThread (the extension that is being currently developed and OpenThread specification changes are pending), so it comes through ieee802154_radio_openthread.h.
Drivers has no duty to support this capability, unless they wants to support the new OpenThread feature.
The implementation is provided for ieee802154_nrf5 driver only.
Upper layers other then OpenThread do not need to be aware of this capability, it is turned off by default even for ieee802154_nrf5.
The ieee802154_nrf5 is aware and turns on the feature if in build-time if relevant OpenThread Kconfig is requested.

[ghost]

Hi @fgrandel could you please have a look on this draft PR? I would like to ask you if this proposal is compliant with adopted rules, especially #61227 .

Hi, sure. As CST is not specified by the IEEE 802.15.4 standard (or is it?), it needs to be encapsulated in OT-specific files, exactly as you did. That's what we have zephyr/include/zephyr/net/ieee802154_radio_openthread.h for.

The only problem I see is the lack of documentation. Please orient yourself to the exact timing diagrams and context that has been documented for the CSL feature. This is the level you should achieve. The reason is to make it obvious to other driver implementers what they have to do to implement this features. As OT is not public any more we cannot even point them to an external spec.

Unfortunately I don't have access to the Thread documents that describe DST. So I cannot be 100% sure that it isn't just another name for an otherwise standard feature. But as you have access to both, OT and IEEE standards, you can check that of course. I guess, though, that it's just the inverse of CSL and that doesn't exist in the standard IIRC.

[Damian-Nordic]

Worth documenting somewhere that this indicates the point of time when the end of SFD/start of PHR for the next transmission will occur.

[ankuns]

Please have a look on doc for IEEE802154_OPENTHREAD_CONFIG_EXPECTED_TX_TIME, it's mentioned there.

[ankuns]

Updated commit metadata