Google Thread protocol vs. BLE Mesh

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

  

  • 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

  • Hi Sigurd

    Thanks for the detailed reply. 

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

    Jeff

  • 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

  • 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

  • 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

Related