[Proposal][bluetooth] Native Multi-Controller Support in Zephyr Bluetooth Stack #93641
Description
Is your feature request related to a problem? Please describe.
Current Zephyr Bluetooth stack binds to a single controller, preventing advanced use cases requiring concurrent operations across multiple Bluetooth radios. Real-world scenarios demand this capability:
- Industrial gateways: Simultaneous BLE scanning on two radios (doubling device discovery speed)
- High-throughput systems: Parallel connections split across controllers (e.g., 10+ BLE sensors)
- Redundant designs: Primary/backup controllers for failover (critical for medical/automotive)
Describe the solution you'd like
We propose extending Zephyr's Bluetooth subsystem to natively manage multiple controllers through Unified Host-Controller Interface:
HCI commands routed via controller ID. Event/callback isolation per controller，eg：
int bt_le_scan_start_mc(uint8_t dev_id, const struct bt_le_scan_param *param, bt_le_scan_cb_t cb);
#ifdef CONFIG_BT_ORIGINAL_API
static inline int bt_le_scan_start(const struct bt_le_scan_param *param, bt_le_scan_cb_t cb)
{
return bt_le_scan_start_mc(0, param, cb);
}
#endif
Describe alternatives you've considered
Proof of Concept
A minimal implementation has been validated on vela project ，such as: discovery, bond, etc.
Benefits to Community
Enable complex radio topologies (e.g., mesh gateways with BLE/15.4)
Reduce BOM cost by leveraging multi-radio SoCs without external switches
Seeking Community Feedback
Architectural alignment with Zephyr's long-term goals?
Next Steps
We will submit an RFC (Request for Comments) PR with core changes if the consensus is positive. A full design document ([Draft Link]) is available for review.