• State Verified Answer
  • Replies 1 reply
  • Subscribers 74 subscribers
  • Views 2146 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 127123
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

A couple of questions regarding mesh

sm117

I've read through a decent amount of the BLE Mesh spec sheet(s), but I still have a few things that I'm not completely sure on. If someone could answer even just a few of these questions, that would be great:

  1. It sounds like a smartphone (with Bluetooth 4.0/4.1) can implement the provisioner service to add devices with Bluetooth 5.0 Mesh to a mesh, but the smartphone itself can't be a part of the Mesh (i.e. it can't send or receive messages) . Is this correct?

  2. If a phone without Bluetooth 5.0 can't be a part of a mesh, how can it control the mesh?

  3. If a device leaves a mesh, the mesh blacklists the device and changes the security key in order to prevent "trash can attacks". Is there any way to prevent this? For example, a wearable device is connected to a mesh at the users home, but they leave their house with the device. How can it reconnect automatically when the user comes back home if the security key has been updated?

  4. A device can belong to multiple different Mesh networks simultaneously, correct? Not just sub-nets, but whole mesh ecosystem.

  5. Can a SiLabs BLE Module work with a Nordic BLE Module in the same mesh as long as they are both using the new official Bluetooth Mesh Standard?

Thanks!

Parents
  • 0
    1. First of all, Bluetooth 5 is unrelated to Bluetooth mesh, so this is not a concern. The phone can be a provisioner and a device. To be a node in the network the phone must implement the Mesh Proxy Service (GATT). The challenge is that currently the phone must implement the Bluetooth mesh stack as part of the app, that is, all layers above bearer. You might want to consider a proprietary GATT service working at the upper layers instead.
    2. As said in 1. it can.
    3. Blacklisting is not automatic. The spec states a procedure that is initiated by the provisioner. When and how this happens is up to the designer of the product/solution.
    4. The specification states that a node can store multiple network keys, so the answer is yes. However, the spec also states that application keys are bound to only one application key, so there are restrictions.
    5. That is basically the point with standards. Bear in mind that some things are Nordic specific, for example the DFU solution.
Reply
  • 0
    1. First of all, Bluetooth 5 is unrelated to Bluetooth mesh, so this is not a concern. The phone can be a provisioner and a device. To be a node in the network the phone must implement the Mesh Proxy Service (GATT). The challenge is that currently the phone must implement the Bluetooth mesh stack as part of the app, that is, all layers above bearer. You might want to consider a proprietary GATT service working at the upper layers instead.
    2. As said in 1. it can.
    3. Blacklisting is not automatic. The spec states a procedure that is initiated by the provisioner. When and how this happens is up to the designer of the product/solution.
    4. The specification states that a node can store multiple network keys, so the answer is yes. However, the spec also states that application keys are bound to only one application key, so there are restrictions.
    5. That is basically the point with standards. Bear in mind that some things are Nordic specific, for example the DFU solution.
Children
No Data
Related
Terms of service