On 11. Jun 2020, at 11.37, Andreas <andreas.schmidt@...> wrote:

So my question: is the scenario to run Bluetooth mesh and Central GAP role simultaneously supported by Bluetooth Low Energy standard?

If so, is such scenario also supported by the Zephyr Bluetooth stack?

There’s nothing in the standard that prohibits it, but it will reduce the efficiency of the mesh network. The mesh advertising bearer is designed in such a way that assumes the nodes to be scanning as close as possible to 100% duty cycle (LPN nodes are an exception). Any connections that you do will reduce the time the controller can spend scanning, and hence reduce the duty cycle.

Currently the Zephyr mesh stack is designed so that it assumes ownership of the advertising and scanning operations, which is why you’ll easily get conflicts and errors if you try to do those yourself. We do have plans to improve this co-existence with the help of multiple advertising instances, but we don’t yet have support for this in the native Zephyr controller (AFAIK). That still wouldn’t help with the central role though, and for that we have plans to introduce HCI-extensions so that the controller would be aware of Mesh-specific scanning and legacy scanning. However, I don’t think there’s any timeline or commitment to getting it done.

To implement what you need with the current stack, and without compromising the efficiency of the mesh network, I’d suggest to consider a HW setup where you have two controllers: one dedicated for mesh and another for the central role.

Johan