Some ideas to implement a "Thread" dongle

[fuxiaoming-lumi]

We want to implement a "Thread" dongle device and interface with third-party manufacturers. The following diagram is our expected architecture.

For this design, we have the following questions. Any advice would be appreciated!

• Whether this “Thread“ dongle can be used as BR to obtain Thread Certification. This is undoubtedly a dongle device designed for BR, but because there is no network interface(for WiFi/Ethernet), I guess it cannot meet the Thread Certification requirements.
• Technically, we want to implement BR functions in this way, and do not make too big changes to the current otbr software architecture. Create a virtual network node "virtual wlan" in our intermediate mcu, and implement a real network node "wlan" on the upper MCU. Then establish a transparent/mirrored/peer-to-peer connection between "virtual wlan" and "wlan" through USB.

[jwhui]

Whether this “Thread“ dongle can be used as BR to obtain Thread Certification. This is undoubtedly a dongle device designed for BR, but because there is no network interface(for WiFi/Ethernet), I guess it cannot meet the Thread Certification requirements.

Without an infrastructure network interface (e.g. Wi-Fi or Ethernet), you won't be able to certify the border router role since there is no way to test the functionality on the infrastructure network interface.

Technically, we want to implement BR functions in this way, and do not make too big changes to the current otbr software architecture. Create a virtual network node "virtual wlan" in our intermediate mcu, and implement a real network node "wlan" on the upper MCU. Then establish a transparent/mirrored/peer-to-peer connection between "virtual wlan" and "wlan" through USB.

The challenge here is that a number of border router services need to operate on the infrastructure network interface, including features like DNS-based Service Discovery (Advertising Proxy, Discovery Proxy) as well as sending/receiving ICMPv6 Neighbor Discovery messages. Depends on what else the host MCU is supporting, those may need some integration with services running on the host. For example, the host MCU ma also need to publish DNS-SD services.

It's not clear to me how to support your proposed architecture without significant changes to the current OTBR implementation.

[fuxiaoming-lumi]

Let me describe our technical architecture more clearly.
Top MCU Host：Use wpantund to provides a native IPv6 network interface to a Network Co-Processor.
Intermediate MCU Host：As the Network Co Processor, it is responsible for communicating with RCP and managing the openthread network layer.
Thread RCP: Only a minimal MAC layer "controller" on the device with the Thread radio.

As I know, it seems that the architecture of wpantund is no longer maintained. We used this architecture to obtain Thread 1.1 certification. Since Thread 1.2/1.3 adds many new functions, such as SRP, we want to know the possibility and workload of this architecture, and we hope to get your suggestions.