Indefinite Sleep mode or Force Standby State

[B_H]

Hi,

Is it possible to remotely execute a command that would force a BLE node into indefinite sleep or standby mode?

I am working to build out a BLE mesh network, where I will need to enable a feature that allows a user to "push a button" to force the entire mesh network into standby state or possibly sleep mode. The user then would also hit the same button to wake the mesh back up without a pre-defined time period to return to normal functionality.

BLE does have a standby state, but I am not having much luck in finding any resources that discuss putting the node into a standby state at the link layer. 

I've seen a ton of discussion on sleep/wake cycles, but I'm looking for hours or days of sleep cycles with the ability to interrupt that cycle back to "wake" at any given moment.

Thanks

[tesc]

Hi,

You typically have the power usage versus latency tradeoff.

It would be possible, at least in theory, to have a mesh network enter a low power mode where it seldom checks for packets. It would however not be a Bluetooth mesh network at that point, as there is no such mechanism in Bluetooth mesh.

Also, it would be time consuming for nodes to get back up from this low power mode, since such a mode would save power through spending less time in RX. The longer time between each RX session, the less power drawn, but the longer latency to get up and running again. The main power consumption for a mesh network comes from RX and TX, so that's the place to save.

You could keep the mesh network running, but equip all nodes with an on/off model for turning the functionality of the node on/off, and send on or off messages as group messages to all nodes on the network. It would let you turn the system on/off, but the Bluetooth mesh network would still run in the background (at normal power consumption), ready for distributing an "on" message for turning everything back on again.

Regards,
Terje

[B_H]

Hi Terje,

I'm not worried about the functionality of the mesh network with it turned off. It would kinda be the point. The use-case would require it to shut down, and then be turned back on remotely whenever the requirement to have it back on was met. 

For the on/off model, are you meaning the deviceoff function message that turns the node off, and requires a physical interaction to turn back on?

The two main objectives would be that I would verifiably be able to remotely shut down all BLE transmission (TX) of all nodes in the group, and then remotely turn them back on. In BLE standby mode, the radio isn't transmitting, but I don't know if I can force the radio to this mode, and then execute a remote command to push it back to normal operation.

[tesc]

Hi,

I am struggling a bit to understand the full use case here. In this "sleep" mode, are we only talking about normal messages over the mesh network not being transferred, or are we talking about the devices themself entering a mode where the radio is disabled?

Obviously in order to remotely control the devices there must be some RX going on. Either that they are in RX all the time (consuming the same amount of power as they would do when running the full mesh network,) or that they wake up periodically to check if they should wake up (which gives a latency to waking up equal to the wake up period.) What kind of power requirements (if any) do you have in sleep, and what maximum latency requirement do you have for wake up?

It should be possible, yes, to disable and enable TX using some signal, and otherwise stay in RX all the time (or enter a low-power mode with periodic RX for listening for packets in order to wake up). It would however involve a separate protocol than Bluetooth mesh for when being in the sleep mode, as Bluetooth mesh by specification do require some TX which cannot be disabled in the stack. The mesh stack must therefore be disabled during sleeping.

Regards,
Terje

[B_H]

The use case is that I need to deploy a normal mesh network, but with the ability to remotely shut down all nodes within the mesh so that they go radio silent. i.e. no BLE transmission what so ever. I need to be able to verify that no RF is being transmitted by the mesh nodes. 

I should also clarify that I understand that the mesh will no longer exist when the nodes are in RX or standby mode or whatever. I'm not worried about maintaining the mesh at the same time. If they are in RX mode only and can receive a remote command to resume normal function, they should inherently through the mesh firmware restart the mesh. 

Understood on the mesh protocol. That's why I was wondering if its at the link layer with putting a BLE device in to "standby" mode. 

If that means that they are placed in a "permanent" RX mode, then that would be perfect. If they are constantly in RX mode, then they would just sit there and wait for the remote command to return to normal function and start relaying data packets across the mesh again. 

For this particular use case, I'm not concerned about latency on the wake cycle. The mesh will handle data capture off of wearables and some IoT environmental sensors. But losing the environmental data is second to ensuring the TX of the mesh is off. The wearables themselves only have their data transmitted every 24 hours or so, so a large majority of the time, they aren't even interacting with the mesh other than maintaining themselves on the network. 

I'm also not worried about power consumption. That is a separate issue to tackle once I get this feature up and running. If in the end I have to hardwire everything to a power source to make this happen, then so be it. Not great, but doable. 

[tesc]

Hi,

Thanks for the clairifications.

Back to your question:

BLE does have a standby state, but I am not having much luck in finding any resources that discuss putting the node into a standby state at the link layer. 

I am not quite sure what you refer to there, as there is no "standby state" or similar in BLE terminology. For instance a BLE Peripheral must advertise (send advertisement packets) in order for a BLE Central to connect to it, while a BLE Central may scan (i.e. RX only) for Peripherals to connect to. During a BLE connection there will be packets both ways.

Bluetooth mesh builds on the BLE Observer/Scanner and the BLE Advertiser roles, where all nodes use the Advertiser role for sending messages and the Observer role for listening for messages from other nodes.

In addition, Bluetooth mesh has a beacon signal transmitted by the mesh network as a collective, such that at any point in the network the nodes will receive one such beacon every 10 minutes. In order to get complete radio silence, therefore, you must disable the mesh stack and instead revert to a simple protocol that you can control 100 % yourself.

Regards,
Terje