Tunnel/Forward Thread over a serial interface to multiple controllers

[Heinz-Peter Liechtenecker]

Hi Experts,

I am currently evaluating the capabilities of OpenThread for ongoing research projects as well as a potential solution for commercial products.

Especially using an IPV6 based systems seems to be very promising and future proof as FOTA-update capability, transparent communication with each device and of course border-router capabilities to transparently forward messages to cloud services perfectly suit my needs.

What I am currently looking at is haven a multi-processor setup in a scalable system: I have a single Microcontroller with wireless capabilities (e.g. Nordic NRF...). Multiple Processors are connected to this single Nordic using e.g. separated Serial-Bus-Channels or a single one with an additional handshake giving only one processor at the time access to the bus to manage concurrency issues. Each processor is capable of running its own e.g. OpenThread Stack with an RTOS like Zephyr. These processors are connected on "PCB-Level".

Each processors in the setup (even the Nordic) shall be able to transparently be part of the Thread-Network (having its own IPv6 address etc.) - which would mean that the processors in some way "share" the radio-frontend of the nordic chip. Or in other words: the nordic acts as a router which is part of the mesh network while forwarding package also to its local serial bus. 

Now coming to my questions:

• Has something similar already been implemented?
  
• Would it be possible to add another "input/output" interface to the OpenThread stack allowing to handle a serial bus as an additional sink/source for Thread packages? If so, which protocol to use? It seems that I simply would "tunnel" the Thread Packages to the Serial-Bus? 
  
• I think the OpenThread Stack would also have to track the hardware-source of the package to perform correct routing? 
• Is there another approach which I have overseen which would give me similar advantages?
  

[Jonathan Hui]

This is an interesting concept. I am not aware of anyone doing anything similar.

One possibility is to update the radio driver to map Extended Addresses to physical transport (i.e. 15.4 PHY or serial bus).

Another possibility is to leverage the multi-radio feature that we recently merged (openthread/openthread#4440) and treat the 15.4 PHY and serial bus as two different "radios".

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/0526f481-1bc3-438f-9966-fdfd5fcc3861n%40googlegroups.com.

[Heinz-Peter Liechtenecker]

Hi Jonathan,

Thanks four your feedback! I will take a look at the multi-radio merge - that could be the perfect starting point to implement a prototype. Does OpenThread already take care of sending traffic from one "radio" to the other? Maybe it comes down to implementing a HAL-"radio" that simply transmits messages on a serial interface to see if the concept would work :)

Kind regards,

Heinz

[Jonathan Hui]

The multi-radio feature will automatically keep track of which physical layer the message was received from to determine which physical layer to use when transmitting messages. Note that when broadcasting messages used for discovering neighbors (e.g. MLE Advertisement), the message will be sent on all physical layers supported by the device. But this is probably what you want in your case.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/a3f80ed1-57d2-4f49-b239-8a3307a9e426n%40googlegroups.com.