Which is currently more stable/complete/fit-for-production, BLE mesh or BLE relay (simultaneous central and peripheral roles)? Is either likely to be simpler to implement?

[JonathanVA]

We are developing a system with multiple sensors that are spaced far enough apart that the furthest sensors won't be able to communicate directly with the user's device (also custom hardware), so either BLE relay or BLE mesh is necessary. We would like to shorten development time and avoid using relatively bleeding-edge technology in order to reduce problems during development and in the field. 

How do BLE mesh and simultaneous central and peripheral roles compare especially for stability, but also for ease of implementation? We noticed that all four simultaneous central/peripheral role/relay example programs in the nRF5 SDK 15 are marked as experimental, and that made us wonder if BLE mesh is preferable from stability/simplicity standpoints. 

I tried searching the Nordic DevZone and didn't see any info comparing the relative stability of multiple simultaneous BLE roles vs BLE mesh. It does seem like mesh would be simpler to develop and use mesh than a complex array of simultaneous roles. 

[David Edwin]

The fruity mesh which uses central and peripheral roles has been using muliple role implementations for quite some time and is likely to have more stability data. BTLE Mesh is also an ecosystem with Mesh Models similar to GATT profiles. If your product or system will benefit from an open ecosystem you should consider the mesh while if your system is a closed ecosystem you can consider central/peripheral roles in addition.

The mesh is fully encrypted and does not have a non-encrypted option when may be overkill for some applications as keys will need to be stored and managed. However in a Central/Peripheral system it may be possible to reduce the key management overheads.