Whole-stack secure CoAP operations and deployment story

[mcr]

I’d really like full 6TISCH… I wish I had time/funding to make that happen.

[jia200x]

@miri64

My interest is more into the same direction I understood @chrysn’s proposal: Use only the MAC layer of OpenWSN. Due to timing constraints I won’t really be able to work on that either. But maybe with the 802.15.4 HAL this turns out to be easier and less time-intensive.

I think it’s hard to argue that a full 6TiSCH implementation (TSCH + 6top + scheduling function) wouldn’t be awesome for RIOT. As described by @fjmolinas, the TSCH part of OpenWSN is already isolated and running on top of the IEEE 802.15.4 Radio HAL. The idea was to isolate the MAC from the upper layer, so we could have run the MAC with 6TiSCH or even non-IP stacks.

Although the port seems to work, it’s relying on VERY dirty hacks and it’s not so configurable. I’m not sure if it would survive basic stress tests. If the goal is to provide a full IEEE 802.15.4 6TiSCH, I wouldn’t recommend to continue on that path since there doesn’t seem to be so much interest on their side to isolate the lower layers. The current OpenWSN MAC is practically hardcoded and cross contaminated with many upper layers. The maintenance burden is way too high IMO to make it reliable.

IMHO I think the only way to support 6TiSCH is either:

1. Implement TSCH from scratch.
2. Find another TSCH implementation that could be hooked into RIOT
3. Use the full OpenWSN stack via the sock API.

If we go for 1., I would definitely try to write TSCH on top of an existing IEEE 802.15.4 implementation (unfortunately not so many…).

For 2., Contiki’s TSCH layer seems like a good candidate IMO. The interfaces are much cleaner than the OpenWSN MAC and the Radio HAL is compatible with the Contiki Radio Abstraction.

We can probably borrow 6top and the scheduling functions from either OpenWSN or Contiki.

3. has it’s limitations (e.g half of the RPL implementation runs on Linux, there’s a second scheduler running on ISR context, etc).

Disclaimer

I still think we would get a lot if we try to integrate the actual IEEE 802.15.4 MAC into RIOT. We just have some dangling components (CSMA senders via SubMAC, IEEE 802.15.4 security) which don’t make them IEEE 802.15.4 compatible. These dangling components end up with RIOT “fifteen-dot-four” nodes that either have an RX Duty Cycle of 100% or 0% (nodes that only transmit). It’s also hard manage security and the nodes are not compatible with real IEEE 802.15.4 nodes (e.g Thread nodes).

Integrating a full 6TiSCH will not take 3 months and a standard IEEE 802.15.4 MAC already provides mechanisms for security, joining/commissioning, low duty cycles (a.k.a low energy consumption) and even slots (GTS).

In fact, we already have support for OpenThread which provides an implementation of beacon-less IEEE 802.15.4. If we add the Sock API on top of it, we can already expect full security and many years of battery life (in case of RFD nodes). This work exists somewhere and it can still be revived, although it’s 5 years old.

Otherwise, integrating OpenDSME (as described above) or even writing the missing components to enable a non-beacon IEEE 802.15.4 can still be very good options and achievable in a relatively short time.