Related to Mesh Network Issue

[Anil.N]

Hi Everyone,

I am new to BLE protocol, and coming to our issue we are working on a project in which we used nRF52840 controller for communication between peripherals in the mesh network and the commands which we are sending through the mobile application are also transferred through the nRF over the mesh network by Broadcasting the commands.

Now we are facing an issue that few peripherals are not receiving the commands in mesh network and so they were not able to respond accordingly.

As a solution we are trying to implement the Handshaking method between the peripherals, but i am not able to get that how exactly to implement the Handshaking method in Broadcasting as i don't know the id's of the peripherals which are connected in the network. and how can we implement handshaking in broadcasting type

Awaiting for helpful reply,

With regards,

ANIL. 

[Simonr]

Hi

Thank you for explaining. So all end nodes are nRF52840 devices, correct? Can you explain what you mean by handshaking, from what I can see there isn't a "handshake" concept in Bluetooth Mesh, so I don't quite understand what you mean here.

One thing that could have happened is that the sequence number counter was cleared or reset at some point. If the sequence number is lower than the highest sequence number seen thus far, the message will be discarded to prevent replay attacks. If you have a limit to the sequence number, it's also possible that it reached the limit before the message got to the end device that were supposed to get it.

The way outgoing sequence numbers are treated and stored, power cycling the device will lead to a "jump" in sequence numbers sent of up to around 8 thousand. Power cycling the device will therefore give a jump in sequence number of 8k which could be use to get it "up to speed" quicker. (The reason for this 8k jump is the number is stored to flash in bulks, to reduce flash wear. Large bulks are "reserved" at a time, and the exact number only held in RAM. On reset, the last sequence number sent may be anything within that bulk, so a new bulk is reserved and numbers start from the beginning of that bulk. With the default bulk size of 8k, each power cycle will get the device to start from the beginning of  the next such bulk. This is implementation specific, and not part of the specification.

If all nodes are broadcasting to all nodes, or all elements on all nodes are broadcasting to one or more elements on all nodes, then the RPL for each node must be large enough to fit all those sender unicast addresses. If that's the case, it would be a good idea to design your solution such that nodes are not relying on receiving messages from all other nodes in the network.

Best regards,

Simon