Many Questions on BLE Mesh Network Custom Implementation

[Nolan_G]

Hello,

I am currently working on a project to make a Bluetooth Mesh network that consists of devices that read and transmit data from on-body sensors. The goal is to have every node in the mesh network transmitting their individual data to reach a smartphone or tablet that can then display the received data in a graph. The graph will be updated live with new information from each node every so often. The data will be sampled from each node once per second, so each node will transmit a new data packet at 1 Hz. 

I should mention now that I am using SDK and toolchain versions v2.4.2, and the device is the nRF5340. I don't believe this matters, but I am using WSL in VSCode. 

As these devices will be on-body sensors, they will be moving around a lot. No single device will always be the device in range of the smartphone. Since smartphones cannot be added as a node to mesh networks, we have two options: 1. we make every node on the network a proxy node, or 2. we have a dedicated proxy node.

I've done some pro/con analysis between these two options, and the most efficient and robust method sounds like having the dedicated proxy node. One of the main reasons for this is the limited pairing needed by the smartphone with the dedicated proxy node. If every node was a proxy node, then we'd have to somehow manage having the smartphone switch (disconnect and connect to new) devices based on whether it was in range to read data. When the smartphone would go out of range of one device, it would be expected to automatically connect to the nearest device to pull data from that new device. This also means that every single device would have to be capable of transmitting data of the entire network over BLE, which adds strain to the device.

There is a lot involved in this system. One extra use-case I should mention is when a single user wants to see his data on a smartphone. We will likely have supported functionality to be able to connect to the device via BLE from an app to be able to read only that single device's data. In this case, the device would need to be a proxy node anyways since it would have to support BLE connectivity.

The two grand use-cases of this device will be: 1. having the data be read via a Bluetooth mesh network, and 2. have the data be read via a BLE pairing peer-to-peer connection.

I believe it would be easier to have a dedicated proxy node because the dedicated proxy node would be a node in the mesh network, meaning it could more easily get data from the network without having to worry about pairing based on signal strength or readability. It could also serve to bridge the network if the network splits: if the smartphone user is standing between two halves of one large network, if he is utilizing a dedicated proxy node that's connected to his smartphone (or is very close to it), then he can bridge the network and read data from both halves easily.

This was a bit of a ramble of thoughts, so I'll give a (barely) more concise list of most of my questions:

1. What are your thoughts on creating a mesh network implementation like this? Is there anything that I haven't listed here that I should consider while making this implementation?

2. What sounds better to you? The dedicated proxy node dongle or having every node act as a proxy that can be connected to at any time (although, this does not sound reliable to me, and from a networking standpoint, sounds like a nightmare!)?

3. How would I go about provisioning nodes on a network if they weren't all proxy nodes? I mentioned that we'll likely leave the proxy setting active due to the desired additional functionality to connect to and read data over BLE from a single device, but if we were to find a way around that and we wanted to disable the proxy node functionality, how would we provision the network via the proxy node dongle?

4. Side question that I've been asked about -- we want to minimize congestion in our network, as we plan to have many (30+) mesh nodes in the network. For segmented and unsegmented Bluetooth mesh packets, I know that the size restraints are 15 bytes and 12 bytes, respectively. I also know that those numbers include the opcode sizes and the MIC sizes. Opcodes can be either 1, 2, or 3 bytes, and the MIC can be either 4 or 8 bytes. However, as far as I'm aware, the opcode size variations are a bit misleading because 1-byte opcodes seem to be dedicated to background essential functionality in Bluetooth mesh, meaning I can't use them (I tried and my Bluetooth mesh simply did not initiate, and gave me an error telling me that my opcode was invalid). 2-byte opcodes seem to be consumed by all of the samples. I am making a vendor model, so I was recommended to use a 3-byte opcode. However, is it possible to use a 2-byte opcode somehow? Can I jerry rig a 2-byte opcode so that I can have an extra byte in my payload? For segmented packets, 12 bytes - 4-byte MIC - 3-byte opcode = 5 bytes of data per fragment. However, if I can get this to 6-bytes, then that may enable us to not have to fragment as much. We're attempting to use a 16-byte packet, and with 5 bytes of payload per fragment, that would require 4 fragments, but with 6 bytes per fragment, we could get away with 3 fragments, which would imply a 33% improvement to the network congestion as we'd be transmitting 3 fragments per second (since we're reading and transmitting data once per second) instead of 4. Also, what are your thoughts on this? Does this matter? Are we underestimating the hardware capabilities of the 5340? Will 3 fragments vs 4 fragments make a noticeable difference in reliability?

5. If we use dedicated proxy node dongles, where each dedicated proxy node will have its own respective mesh network, will it matter if we made all of those networks on one smartphone? To give an example, let's say we have 80 devices total, and we split it into 4 networks of 20 devices each. If we added a node to each of those networks (to total to 21 devices per network), and that node was a dedicated proxy node, would it break the system if all 4 of those networks were provisioned and put into groups on one smartphone? Our plan is to have one smartphone per dongle, and each of those networks of 20 devices would be managed by that one person with that one smartphone and dongle, so there'd be 4 people involved. By managed, I mean that one person would read data from the 20 devices in the network and plot it on a graph on their smartphone app. If they wanted to exchange dongles to exchange networks, would they be able to connect to their respectively new proxy node dongle and have it stream the data packets over BLE to the new smartphone to get data from all 20 devices in the new network?

6. Additional question related to the above question: if we had 80 devices on one large network, and 4 additional devices that acted as proxy node dongles with one smartphone paired per dongle, does that mean that each smartphone/dongle pair would be able to receive data from the large network of 80 (+4) devices?

I've tried to refrain from requesting to "see" large networks from new smartphones since I don't really need to see their mesh network topology from an NRF-mesh-like app, I just need to be able to read data from each device.

This was a very long post, and may not be coherent in some areas (apologies, my thoughts were a bit jumbled as I was writing), so let me know if there are any questions.

Thanks!

[Hung Bui]

Hi Nolan, 

Before going into detail regarding your questions. Please give us more information about your application. 

You mentioned on-body sensors, but you also mentioned that they can be located outside of the smartphone range. Do you mean that you mount the sensors on multiple persons ? 

How do you power them ? Please be aware that a mesh network can only operate if you have enough backbone nodes (relay nodes) that has the RF range cover the whole network. And to act as relay node, the device usually need to connect to main power. 

Please try giving us as much information as possible about your application otherwise it's hard to give our advice on something we don't fully understand.  

Regarding your question about the payload size, I am not sure you are having the correct information. Please take a look at section 2.3.3 (Messages) and section 3.7.3 (Access Payload). You should have 11 bytes payload (unsegmented) at access layer with 1 or 2 bytes opcode. 

[Nolan_G]

Hi Hung, thanks for the reply!

Hung Bui said:

You mentioned on-body sensors, but you also mentioned that they can be located outside of the smartphone range. Do you mean that you mount the sensors on multiple persons ?

When I say on-body sensors, I mean a device that utilizes the 5340 and has peripheral sensors. We're making a biosensor device that measures biosignals, and there will be more to it than just the 5340 and some sensors. There will also be its own power supply, which I will get more into later. The reason why these sensors can be located outside of a smartphone range is because their intended use is for groups of people being managed by one person, like a bunch of patients being monitored by one nurse in a hospital. The intended use is for that one nurse to see the biosignals on every patient, which would be measured and reported via the biosensor device. The biosensor will be mounted on-body but will not be reporting to that individual's smartphone, and will instead be reporting to the nurse. Ideally, the use for the mesh network is so that biosignal packets can be sent through the network of patients to reach the nurse, thinking in the case of there being a large room with a lot of injured people that reaches beyond the range of a single BLE connection (hence the mesh being used to expand the range to the whole room).

Hung Bui said:

How do you power them ? Please be aware that a mesh network can only operate if you have enough backbone nodes (relay nodes) that has the RF range cover the whole network. And to act as relay node, the device usually need to connect to main power. 

We have a team of engineers making a rechargeable battery for this. We expect that the network may disconnect when there aren't any relay nodes to create bridges for all nodes. If there is a part of the network where there aren't any two nodes close enough to establish a connection, these two parts would be treated as subnetworks. Hence the idea that a proxy-node dongle connected to the smartphone of the nurse could be used to bridge that connection, since the nurse would be walking around. Even if parts of the network don't reliably receive data from other parts of the network, the goal would just be for all of the packets to reach the nurse so that they can monitor every patient. We've tested a smaller situation with the lightbulb example and saw that we can connect our 5340 DKs to battery packs and walk around while still getting signals. We figured that the reliability of the packet transmission would be related to the strength of the Bluetooth radio. If recommended, I can discuss with my PCB development team that we may want to use a stronger radio, and they can find a stronger one on Digikey or through some provider.

Hung Bui said:

Please try giving us as much information as possible about your application otherwise it's hard to give our advice on something we don't fully understand.  

Hopefully this clears up a lot. If not, definitely let me know and I can fill you in with as much necessary.

Hung Bui said:

Regarding your question about the payload size, I am not sure you are having the correct information. Please take a look at section 2.3.3 (Messages) and section 3.7.3 (Access Payload). You should have 11 bytes payload (unsegmented) at access layer with 1 or 2 bytes opcode. 

According to SDK v2.4.2, in \include\zephyr\bluetooth\mesh\msg.h:

I agree that we have 11 bytes before opcodes (15 bytes total - short MIC size (4 bytes)), but I was removing the size of the opcode to calculate the available bytes for data. So, 11 bytes - 2 byte opcode = 9 bytes that we can fill in with sensor data. Since we have to use a vendor opcode (I think?), we consume 3 bytes with our opcode, leaving 8 bytes for data or 5 bytes when using a 12-byte segmented packet.

Let me know if that makes sense.

Thanks again!

[Hung Bui]

Hi Nolan, 

Thanks for the clarification. It's clearer now. 

Usually for hospital setup we often seen it's the combination between mobile on-body sensor devices and the static main powered backbone node that deployed in the hospital. 

Of course it's a design choice to have the main powered nodes or not.

I assume you have done your calculation on the battery life of the sensor device if it's used as a relay node. In our test with the Thingy52 with 1440 mAh battery ,it often last less than 24h. 

The challenge of having all mobile mesh network is what you already described. It can be fragmented into multiple segment where they can't communicated with each other and can't relay the data because they are out of range of each other. 
This is especially true when you are using these nodes inside a building. 

So you will have to accept that you will run into situation that the nurse will not be able to get the sensor data from some part of the network because they are out of range. Even though there is a chance that a node may act as a bridge and relay the message to the proxy node and to the nurse's phone. But there is no guarantee for that. 
So I don't know how you will cope with such situation that multiple "subnet" is formed and you can't get data from all the "subnet"

I use "subnet" with the mark because there is a subnet term in mesh that they are part of a full network but they use different netkey, forming a virtual sub network. It may not related to the "subnet" we are discussing here. 

In your situation, when you usually don't have control over the location of each sensor node, I think setting all the node to be proxy node would be the solution. You will need to reduce the advertising interval of each of the node to avoid congestion. It will increase the latency for the phone to be able to connect to a node. 

Thing are easier if you have dedicated wall mounted node in each floor or room for example. They will act as the gateway and you only need to configure them as the proxy&relay node when sensor nodes will only the be the leaves, without doing relay. But of course if this is not possible then we will have to look at what we can do without them. 

Regarding the payload, sorry that I didn't read it properly. Yes you will need to use 3 bytes opcode. But you only have to transmit the opcode in the first segmented packet, not on the 2nd and so on. It's not recommended to transmit a very long message as the segmented packet has a lot of overhead and it take multiple packets back and forth to re-transmit if only one segmented packet is lost. 

[Nolan_G]

Thanks for the info, Hung!

Hung Bui said:

I assume you have done your calculation on the battery life of the sensor device if it's used as a relay node. In our test with the Thingy52 with 1440 mAh battery ,it often last less than 24h. 

We talked to some Nordic FAEs yesterday and we discussed our power solutions. My manager mentioned that our custom rechargeable battery will be able to hold charge for roughly 24 hours, and our battery will also be replaceable, meaning that each person can have multiple batteries and swap them out to maximize the lifespan of the device.

Hung Bui said:

The challenge of having all mobile mesh network is what you already described. It can be fragmented into multiple segment where they can't communicated with each other and can't relay the data because they are out of range of each other. 
This is especially true when you are using these nodes inside a building. 

So you will have to accept that you will run into situation that the nurse will not be able to get the sensor data from some part of the network because they are out of range. Even though there is a chance that a node may act as a bridge and relay the message to the proxy node and to the nurse's phone. But there is no guarantee for that. 
So I don't know how you will cope with such situation that multiple "subnet" is formed and you can't get data from all the "subnet"

I agree that this is a problem that's not easily solvable. We can't increase the range beyond what the Bluetooth radios are capable of, so if there aren't nearby nodes connecting devices to the smartphone, then there's not much we can do. Having the nurse walk around with a dedicated proxy node could minimize the situations when there are multiple subnets as that could be a bridge for the network. I don't think the smartphone itself can ever be a bridge because it can't act as a mesh node, and it would also need to try to manage getting data from both subnets simultaneously, which would be difficult. Streaming all relevant data from one node to the phone would also be easiest to manage on the app side. Are there any concerns with a dedicated proxy dongle? This is the direction I'm planning to take the project as it sounds most practical to me. Let me know what you think.

Hung Bui said:

In your situation, when you usually don't have control over the location of each sensor node, I think setting all the node to be proxy node would be the solution. You will need to reduce the advertising interval of each of the node to avoid congestion. It will increase the latency for the phone to be able to connect to a node. 

Based on the latency and congestion concerns, don't you think it'd be better if we had a single dedicated proxy node that was attached to or very close to our smartphone as we walked around the hospital? That way, there won't need to be any pairing between the smartphone and the multiple proxy nodes, but the smartphone will only have to pair with the dedicated dongle once. The dongle would maintain a mesh connection so it would always get the data broadcast throughout the network.

Hung Bui said:

Regarding the payload, sorry that I didn't read it properly. Yes you will need to use 3 bytes opcode. But you only have to transmit the opcode in the first segmented packet, not on the 2nd and so on. It's not recommended to transmit a very long message as the segmented packet has a lot of overhead and it take multiple packets back and forth to re-transmit if only one segmented packet is lost. 

This is good to know! I hadn't thought about how the opcode only needs to be sent once, so that makes sense.

Let me know if you have any other thoughts about this project. I'd like all the guidance I can get to make this work as well as possible. Thanks!

[Hung Bui]

Hi Nolan, 
I misread the part when you mentioned that the nurse may carry an extra device to the phone. I was thinking of the situation where you have many nurses and you don't have a dedicated device on each personnel except for a smart phone. 

In that case, where you can have an extra device can be carried on with the nurses,  I agree that you just need only these device acting as proxy to connect to the phone. And you can program these devices as "the collectors". The Collector can have the storage memory to collect data from all the nodes in the network and if it will move around in the building it has higher chance of being exposed to all the scattered subnets in the building. 

This way you don't need to have the phone to connect to the proxy device all the time to get the sensor information and only occasionally connect to get the data dump from the storage on the proxy device. The data may not be realtime , but it should be the latest data from the last time the device connected to the subnet. 

My suggestion is still considering having dedicated relay devices at certain places in the building acting as the backbone nodes, or at least as the bridge nodes for the areas that you usually have split networks.