Topics

Embedded Border-Router - Route Thread-Protocol to Serialbus


Liechtenecker Heinz-Peter Ulrich <H.Liechtenecker@...>
 

Hi,
I am currently investigating Zephyr and Thread for various use cases and I did a lot of research, but there are still a lot of open questions left. I tried to avoid opening an issue, but I am quite unsure. where to ask my questions. So, before I deep-dive into the Zephyr world, some advice and hints would be nice to have. 

**Creating an Embedded Border-Router for Thread**
As far as I understood, Zephyr uses OpenThread under the hood. Users can take advantage of the common Zephyr Networking API - they do not directly interact with the L2 layer (where OpenThread is actually hidden). So, Thread defines several roles - one is the Border Role. The Zephyr-Documentation states that I can activate multiple Network Interfaces at the same time, however, no automatic IP routing is done. So, it should be no great problem to implement a Thread Border router?

So far so good, for my specific needs I would like to implement a Border-Router based on e.g. Lairds Pinnacle 100. So, the Border-Router I am thinking about would be running Zephyr which would perform routing between Thread and the Modem (in an industrial environment, so I do not expect users to manually add devices, they may be pre-configured - so no HTML server etc. is necessary). 

- Which steps would I have to take to implement such an embedded border router? And is this even a good idea? Maybe some experts do have some advice. (I have seen that there are some commits in the latest OpenThreads commits addressing Border-Routing and Backbone-Routing - so maybe it would. be an idea to use OpenThreads routing capabilities?)
- How do I set the corresponding Thread-Role for my device? (Router, Border-Route, End-Device...)
- What about https://github.com/zephyrproject-rtos/zephyr/issues/3861 ? Which features shall be available through this management interface?

Zephyr greatly abstracts all network-related features, at the same time it makes using OpenThread somehow intransparent….

**Additional processors on a serial bus**
I really do like the idea of a transparent IPv6 based network down to each device/processor. My specific hardware may consist of several (and optional) processors - connected to e.g. a Nordic device using a serial bus. Each processor runs zephyr and hence has its own OpenThread Stack. However, the processors connected via serial act as **end devices** while the Nordic acts as a **router**. The router bridges messages to the serial bus and the radio at the same time. The following figure hopefully clarifies the topology:
If I get this to work, it would allow me to send e.g. FOTA updates to each processor without any additional protocol etc. - I am not sure if this question is more related to OpenThread or Zephyr. I would like to know if something similar has already been tested/implemented and if so, where to start? I think one would have to add an additional interfaces to OpenThread - so the Router would have to track where to send packages to. Maybe an expert has some better ideas to accomplish such a topology without adding a lot of additional protocols? 

I did also ask the question in the OpenThread [mailing list](https://groups.google.com/g/openthread-users/c/RwYZJS2_IfQ/m/S2qNRaQwBwAJ) - so it would be a good idea to focus on the Zephyr part of the question.


Becker Markus
 

Hi.

 

> **Creating an Embedded Border-Router for Thread**

 

Currently there is support for the NCP as well as the RCP configuration of an OpenThread BR within Zephyr (https://openthread.io/platforms/co-processor) next to the router/end-device device types.

 

NCP as well as RCP already use UART (or SPI) as a lower layer to send IP messages to an application processor. Zephyr’s OpenThread UART adaptation is at https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/openthread/platform/uart.c.

 

If you run the host-side BR tools also on the micro-controller, this would make a very cost-efficient BR, but also a more restricted one. E.g. it will be harder to do firewalling, routing, service discovery, and WebUI things. It is definitely possible. If you work on this, let the mailing list know.

 

> **Additional processors on a serial bus**

 

From the figure and the description, it seems that you want to use the serial link as a thread link. This is similar to the TREL feature Jonathan pointed out on the openthread mailing list. TREL is there to use Ethernet as a Thread link. Note that TREL is not (yet) included within OpenThread on Zephyr.

 

BR,

Markus

 

From: users@... <users@...> On Behalf Of Liechtenecker Heinz-Peter Ulrich via lists.zephyrproject.org
Sent: Samstag, 16. Jänner 2021 18:13
To: users@...
Subject: [Zephyr-users] Embedded Border-Router - Route Thread-Protocol to Serialbus

 

Hi,

I am currently investigating Zephyr and Thread for various use cases and I did a lot of research, but there are still a lot of open questions left. I tried to avoid opening an issue, but I am quite unsure. where to ask my questions. So, before I deep-dive into the Zephyr world, some advice and hints would be nice to have. 

 

**Creating an Embedded Border-Router for Thread**

As far as I understood, Zephyr uses OpenThread under the hood. Users can take advantage of the common Zephyr Networking API - they do not directly interact with the L2 layer (where OpenThread is actually hidden). So, Thread defines several roles - one is the Border Role. The Zephyr-Documentation states that I can activate multiple Network Interfaces at the same time, however, no automatic IP routing is done. So, it should be no great problem to implement a Thread Border router?

 

So far so good, for my specific needs I would like to implement a Border-Router based on e.g. Lairds Pinnacle 100. So, the Border-Router I am thinking about would be running Zephyr which would perform routing between Thread and the Modem (in an industrial environment, so I do not expect users to manually add devices, they may be pre-configured - so no HTML server etc. is necessary). 

 

- Which steps would I have to take to implement such an embedded border router? And is this even a good idea? Maybe some experts do have some advice. (I have seen that there are some commits in the latest OpenThreads commits addressing Border-Routing and Backbone-Routing - so maybe it would. be an idea to use OpenThreads routing capabilities?)

- How do I set the corresponding Thread-Role for my device? (Router, Border-Route, End-Device...)

- What about https://github.com/zephyrproject-rtos/zephyr/issues/3861 ? Which features shall be available through this management interface?

 

Zephyr greatly abstracts all network-related features, at the same time it makes using OpenThread somehow intransparent….

 

**Additional processors on a serial bus**

I really do like the idea of a transparent IPv6 based network down to each device/processor. My specific hardware may consist of several (and optional) processors - connected to e.g. a Nordic device using a serial bus. Each processor runs zephyr and hence has its own OpenThread Stack. However, the processors connected via serial act as **end devices** while the Nordic acts as a **router**. The router bridges messages to the serial bus and the radio at the same time. The following figure hopefully clarifies the topology:

If I get this to work, it would allow me to send e.g. FOTA updates to each processor without any additional protocol etc. - I am not sure if this question is more related to OpenThread or Zephyr. I would like to know if something similar has already been tested/implemented and if so, where to start? I think one would have to add an additional interfaces to OpenThread - so the Router would have to track where to send packages to. Maybe an expert has some better ideas to accomplish such a topology without adding a lot of additional protocols? 

 

I did also ask the question in the OpenThread [mailing list](https://groups.google.com/g/openthread-users/c/RwYZJS2_IfQ/m/S2qNRaQwBwAJ) - so it would be a good idea to focus on the Zephyr part of the question.


The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.