Google Thread protocol vs. BLE Mesh

[Jeffery]

Hi Nordic team

I am skilled in BLE Mesh and developed BLE mesh at several projects.

At BLE mesh, 

1. Provisioner was hard-code consistent. It could be smartphone with nRF Mesh apps or standalone solution as a Nordic chip.

2. Provisionee broadcasted unprovisioned beacon to let provisioner find it and add it to this network. Then, this provisionee become a node in this network.

3. Provisioner can configure models of every node in order to divide all nodes in network into several groups. Then, client node can control multi server nodes in same group. 

My questions about Thread

Q1. Tested COAP client and COAP server, client can send multicast message to all FTDs/MEDs. Or, single paired between client and one server, client can send message

       only to paired server. If we want group division same as BLE mesh, can Thead make it? Through which interface to manually configure it? As BLE mesh, user can configure group at

       smartphone.

Q2. If we selected COAP client and server samples at nrf SDK connect as a start point to develop our own project, it seems nothing to do for Thread network management, after reboot many

       client and many server devices, they will form a Thread network automatically, including who was leader, who was assigned to commissioner, controlling router numbers (16~23), router

       path and others. So, what we can do at a device is very simple to send or receive user message data after network was formed. Right?  

Q3. For Q2, if there are two independent Thread networks at office A and B. Several COAP client and server devices in each office. How can I modify code or parameters in COAP samples

       to prevent communication between office A and B?

Q4. At COAP client and server samples, after commission done, did the network information store at flash memory?

Q5. Did Thread define model spec. similar as BLE mesh?

Thanks

Jeffery

  

[Sigurd Hellesvik]

Hi Jeffery,

One of the big differences between Thread and Bluetooth Mesh is that Thread does not define an application layer.

Therefore you will have to use an application on top of Thread. This is commonly applications such as CoAP, MQTT or Matter(*).
(*) Matter is a lot more than just an application, but it used Thread for transporting data.

With this in mind, let's get to the questions:

Q1. Tested COAP client and COAP server, client can send multicast message to all FTDs/MEDs. Or, single paired between client and one server, client can send message

       only to paired server. If we want group division same as BLE mesh, can Thead make it? Through which interface to manually configure it? As BLE mesh, user can configure group at

       smartphone.

For some theory, see Openthread guide.

In Thread, nodes are configured with a PanID.
Simplified, only nodes with the same PanID connect to make a network.

If you want more separation between Thread nodes than this, I think you will have to do this on the application layer.

You mention "Server" and "Client". Thread does not have Servers and Clients. CoAP, the application layer has Servers and Clients.
These function similar to http, where you can make end-to-end connections.

As I understand it, for BLE mesh groups, you can publish to groups and them a device can be subscribed to one or more groups, right?
In that case, this sounds a lot like the MQTT application layer, which can do the same, but calls the Groups for Topics.
I should mention that MQTT is built on TCP, which might use more power than CoAP which uses UDP.

To sum this up: Thread does not have this group functionality in itself. You need to handle that in an Application.

Q2. If we selected COAP client and server samples at nrf SDK connect as a start point to develop our own project, it seems nothing to do for Thread network management, after reboot many

       client and many server devices, they will form a Thread network automatically, including who was leader, who was assigned to commissioner, controlling router numbers (16~23), router

       path and others. So, what we can do at a device is very simple to send or receive user message data after network was formed. Right?  

Thread networks are formed if the devices have the same values for all these:

• panid
• extpanid
• channel
• networkkey

These are set to defaults for the CoAP Client and Server samples.
I recommend that you try to use the Thread CLI sample to test to set these manually. Then you test different values and see how the network connects.

In Thread you can use a process called Commisioning to add a device to a thread network by using only a password. The Commisioner is usually only active for a limited time.
If you want to test this, I have two examples based on the CoAP Server and Client that does commisioning at my git.

If you want to know more about which communication options you have with the CoAP Server and Client, look up the CoAP protocol.

Q3. For Q2, if there are two independent Thread networks at office A and B. Several COAP client and server devices in each office. How can I modify code or parameters in COAP samples

       to prevent communication between office A and B?

Use different PanID for networks.

For more information see Network Discovery and Formation

Q4. At COAP client and server samples, after commission done, did the network information store at flash memory?

Yes. If you enable Thread, it generally saves network information persistently.
To test this, run the Thread CLI sample to connect to a network. Reset the CLI sample and check the panid etc.

Q5. Did Thread define model spec. similar as BLE mesh?

No. The model spec is an application layer feature.

Protocols built on top of thread might have such a model specification.
Matter for example has a specificaion for Clusters I think.

To learn more about Thread, see our documentation on the Thread Protocol as well as webinars on Introduction to Thread networking protocol and Developing Thread products with nRF Connect SDK.

Regards,
Sigurd Hellesvik

[Jeffery]

Hi Sigurd

Thanks for the detailed reply. 

Another simple question. How many bytes at most for customer data a Thread packet?

Jeff

[Sigurd Hellesvik]

Hi Jeff,

Jeffery said:

Another simple question. How many bytes at most for customer data a Thread packet?

Does this thread in googles openthread forum answer your question?

Regards,
Sigurd Hellesvik

[Jeffery]

Yes,thanks a lot. Max. 1280 bytes was enough for my project. Another question for COAP client and server samples. Did these two samples really run commissioning process before they can talk each orther? Or, they can talk because they have same thread parameters in advance,like panid and ,network key? I

[Sigurd Hellesvik]

Hi,

Jeffery said:

Did these two samples really run commissioning process before they can talk each orther?

No

Jeffery said:

Or, they can talk because they have same thread parameters in advance,like panid and ,network key?

Yes

However, I have a an unofficial sample which is CoAP Client+Server with automatic commissioning if you need that.
This sample is just a modified version of the official CoAP Client and Server samples in the nRF Connect SDK.

Regards,
Sigurd Hellesvik

[Jeffery]

Thanks. So, actually, commissioning is not all necessary for thread communication. It just let both sides got same thread configurations, right?

[Sigurd Hellesvik]

Thread devices with the same thread configurations will automatically connect yes.

But in the field, you likely want devices to use commissioning instead.
Here are some reasons to why:

• Thread devices for smart homes often needs to work on other thread networks. If you hard-code Thread configs, devices can only work with your devices(as only they have the same config). You loose interoperability.
• Security is a nice feature in Thread networks. If consumer A buys your thread device, consumer B can buy another of the same device and connect to Consumer A home network without Consumer A knowing.

So it is most often better to have thread networks with generated network configurations and use Commisioning.

Regards,
Sigurd Hellesvik

[Jeffery]

Hi Sigurd

I tried ur  CoAP Client+Server with automatic commissioning samples.

 Below was what I did

- Download ZIP of samples_for_nr_connect_sdk. Unzopped it amd extracted commissioner and joiner

  folders to my local folder.

- At VS code,  "Adding an existing application" for commissioner and joiner folders each.

- Then, build configuration was nrf52840dk_nrf52840.

At SDK v2.2.0 environment, Build failed for both projects. It showed "FATAL ERROR command status 1"

At SDK v2.1.2 and v1.9.1, build successfully.

- Then, flash commissioner and joiner to two DK boards. Open serial terminal for both.

- At commissioner, "ot commissioner start" and "ot commissioner joiner add * J01NU5 20"

 DK returns "Done" without problem.

 However, after 20 seconds timeout, it showed "joiner remove". The results were 

 same for v2.1.2 and v1.9.1.

Q1. Shall I send any "ot" command to joiner board? 

Q2. How can I solve SDK2.2.0 build failed issue?

Q3. If commissioning was successful, how to verify they are at same network? Only

    by "ping"?

Jeff