Wi-SUN implementation and 802.15.4 status

Hello all,

As a French ASIC/SoC Design company, Cortus is currently designing a SubGHz SoC for User Equipment. In this context, Cortus is looking to develop/integrate a full Wi-SUN network stack based on RIOT. At a first stage, we want to get confirmation about what can be leveraged natively on RIOT to fulfil the Wi-SUN requirements, but also, to point out what is precisely missing.

As an early adopter of RIOT, we are ready to contribute for advancing the RIOT’s state of the art if this Wi-SUN support makes sense for the whole RIOT community. As a preliminary, you can find below the WI-SUN architecture:

Ideally, we are looking to leverage a maximum number of native components from RIOT, and we came to the following mapping:

  1. UDP Transport layer → gnrc_udp module
  2. Network layer → gnrc_ipv6 / gnrc_icmpv6 / gnrc_rpl modules
  3. Data link layer → gnrc_sixlowpan and gnrc_netif_ieee802154 modules But we don’t know how far the current gnrc_netif_ieee802154 supports 802.15.4e with IE extensions as listed below:
    • Radio Frequency Identification Blink (BLINK)
    • Asynchronous multi-channel adaptation (AMCA)
    • Deterministic and Synchronous Multi-channel Extension (DSME)
    • Low Latency Deterministic Network (LLDN)
    • Time Slotted Channel Hopping (TSCH)
    • Low Energy (LE)
    • Information Elements (IE)
    • Enhanced Beacons (EB)
    • Multipurpose Frame
    • MAC Performance Metrics
    • Fast Association (FastA)

From our understanding, gnrc_gomach module should support the “Time Slotted Channel Hopping (TSCH)”. Is that assumption correct ?

  1. As for the MAC sub-layer can we use dev_ieee802154_submac module, is it 802.15.4g compliant?
  2. On the security side, we know about the latest introduction of the IEEE 802.15.4 security module. But is that enough to fullfill Wi-SUN security requirements?

On the PHY layer, we are using our own netdev driver dedicated to our SoC (which shall remain private) but we are willing to enhance a netdev driver (eg Atmel AT86RF2xx driver) to fully support the specification 802.15.4g and to enable a Wi-SUN capable platform supported by RIOT.

Before submitting a feature request related to this Wi-SUN support, we would appreciate to get your first feedback in order to clarify and consolidate our project and roadmap.

Thank you in advance,

Christos and @Mattheouus

1 Like

I can’t speak to the precise state of the 802.15.4 extensions support in RIOT (other than that not all you list is supported yet), but am curious about the modes you list: In my understanding, TSCH and DSME are two distinct modes of operation. Are they both required for Wi-SUN operation, and if so, are they to be selected at build or at run time?

The security module currently provides frame encryption and decryption, but AFAICT we do not have any support for the EAP-TLS and group key management yet. As for EAP-TLS, how would that be transported? I’ve recently had a look at EAP-over-CoAP, would that be used here?

I’m not sure I understand the relation between the existing netdev driver and that of yours: Does the AT86RF2xx series contain all the hardware needed for Wi-SUN operation? If not (and there is no other board with which it can be tested), it’d be hard to review these components.

On the closed netdev driver, while this is certainly possible with RIOT’s licensing, you may find that the user adoption of your hardware can greatly benefit from opening up there (the good support of nRF’s radio stack vs. the still-stalled state of the EFM/EFR drivers shows that). If you want to explore what works with the precise constraints you’re working with, we might ways to ease the development experience there. (Also in private communication, if that helps things).

Others can probably say more about what’s precisely missing, but with some joint work this looks like it would make good use of existing components and infrastructure. I’d be glad to have a full Wi-SUN device supported in RIOT!

Hello Christos,

I wrote a reply email some hours ago but it seems it got lost.

I post the original reply (many topics already covered by the reply of @chrysn ) and also add something regarding the AT86RF2XX series: The at86rf215 is already compatible with WI-SUN. Could you specify which components are you considering in the netdev driver you describe?

Otherwise, please see inline reply.

On 21/11/25 10:34AM, christos eleftheriadis via RIOT wrote:

Hello all,

As a French ASIC/SoC Design company, Cortus is currently designing a SubGHz SoC for User Equipment. In this context, Cortus is looking to develop/integrate a full Wi-SUN network stack based on RIOT. At a first stage, we want to get confirmation about what can be leveraged natively on RIOT to fulfil the Wi-SUN requirements, but also, to point out what is precisely missing.

As an early adopter of RIOT, we are ready to contribute for advancing the RIOT’s state of the art if this Wi-SUN support makes sense for the whole RIOT community. As a preliminary, you can find below the WI-SUN architecture:

Having WI-SUN support in RIOT makes 100% sense! That sounds promising and really looking forward to that!

Ideally, we are looking to leverage a maximum number of native components from RIOT, and we came to the following mapping:

  1. UDP Transport layer → gnrc_udp module
  2. Network layer → gnrc_ipv6 / gnrc_icmpv6 / gnrc_rpl modules

These layers definitely make sense and can be used for Wi-SUN support.

  1. Data link layer → gnrc_sixlowpan and gnrc_netif_ieee802154 modules But we don’t know how far the current gnrc_netif_ieee802154 supports 802.15.4e with IE extensions as listed below:
    • Radio Frequency Identification Blink (BLINK)
    • Asynchronous multi-channel adaptation (AMCA)
    • Deterministic and Synchronous Multi-channel Extension (DSME)
    • Low Latency Deterministic Network (LLDN)
    • Time Slotted Channel Hopping (TSCH)
    • Low Energy (LE)
    • Information Elements (IE)
    • Enhanced Beacons (EB)
    • Multipurpose Frame
    • MAC Performance Metrics
    • Fast Association (FastA)

From this list, I see a mixture of operation modes, frame types/structure and misc. I will differentiate them and reply one by one. Note that the default RIOT IEEE 802.15.4 support does not implement association, scanning, roles, etc. They are just “CSMA-CA senders”. However, we support TSCH via OpenWSN. Plese refer to this WIP document for more details

Operation modes:

- Radio Frequency Identification Blink (BLINK)
- Asynchronous multi-channel adaptation (AMCA)
- Low Latency Deterministic Network (LLDN)

These ones are not supported.

- Deterministic and Synchronous Multi-channel Extension (DSME)
- Time Slotted Channel Hopping (TSCH)

As mentioned above, TSCH is supported via the OpenWSN package. We are currently working on porting OpenDSME into RIOT, so it should also be available in the near future.

Frame types/structure

- Information Elements (IE)
- Enhanced Beacons (EB)

These two are implemented by the packages OpenDSME and OpenWSN, since these structures are required by DSME and TSCH.

- Multipurpose Frame

AFAIK these are not implemented in RIOT nor provided by any of the IEEE 802.15.4 pkgs.

- MAC Performance Metrics
- Fast Association (FastA)

We have some L2 metrics in RIOT. Regarding Fast Association, we don’t have support on RIOT.

From our understanding, gnrc_gomach module should support the “Time Slotted Channel Hopping (TSCH)”. Is that assumption correct ?

No, gnrc_gomach is a different MAC layer and it’s not part of the IEEE 802.15.4 standard.

  1. As for the MAC sub-layer can we use dev_ieee802154_submac module, is it 802.15.4g compliant?

Yes, it is 802.15.4 compliant, but note this layer only provides routines associated to data transmission (CSMA-CA, retransmissions). It does not implement association, roles, scanning, etc.

  1. On the security side, we know about the latest introduction of the IEEE 802.15.4 security module. But is that enough to fullfill Wi-SUN security requirements?

Only speaking about the security module, it should suffice. However, note that this module only provides the encryption scheme.

On the PHY layer, we are using our own netdev driver dedicated to our SoC (which shall remain private) but we are willing to enhance a netdev driver (eg Atmel AT86RF2xx driver) to fully support the specification 802.15.4g and to enable a Wi-SUN capable platform supported by RIOT.

The netdev driver for IEEE 802.15.4 is being replaced by the IEEE 802.15.4 Radio HAL, which is already used by the SubMAC, OpenWSN and the upcoming port of OpenDSME. We are currently trying to write bare minimum drivers (just the transceiver and minimal acceleration) and leave the MAC tasks to the upper layers (SubMAC, etc). Same as the SubMAC, the IEEE 802.15.4 Radio HAL was designed to be compatible with the IEEE 802.15.4g.

Before submitting a feature request related to this Wi-SUN support, we would appreciate to get your first feedback in order to clarify and consolidate our project and roadmap.

It would be nice to have a clear picture of the minimal requirements for Wi-SUN, so we can try to synchronize efforts. Many of the potential requirements are spread between RIOT code and package support, so we would definitely need to organize some blocks.

But the whole idea already sounds quite nice!

Cheers,

Thank you in advance,

Christos and @Mattheouus

1 Like

My understanding is that Wi-SUN does not use TSCH mode. Maybe that’s changed. It does use the “g” PHY which allows up to 1500 byte frames.

No, CoAP-EAP is completely useless here. (I think it’s completely useless, period. But, the point is that it’s not in the Wi-SUN spec)

In general, I think that RIOT-OS could provide WI-SUN support, and I’d love to see that happen. I think that it would take 3-5 months of effort from a team of three to make it happen.

Hello,

Thank you all for your valuable feedback. It’s good to see that the RIOT Community is quite enthusiastic about it.

Indeed, we should first have a clear picture of the minimal requirements for Wi-SUN and especially on the MAC and PHY layers.

So I guess we should aim to support a Reduced Function Device (RFD) or a “leaf” node as Wi-SUN describe it. We will explore this and come back to you guys once this assessment is done.

Regards,

Christos and @Mattheouus