Thanks for the work done on BLE Mesh but I have to agree with the request to support GATT and BLE Mesh simultaneously on a single controller. There are many applications that use GATT for higher bandwidth point to point connections used in OTA update where the overhead and functionality of mesh are not needed or wanted. Until Mesh supports routed packets large SAR uploads flood the mesh network and make OTA over mesh nearly impossible when the node count goes above 4 relay nodes. Limiting the number of GATT nodes to 1 at a time is not a problem for our application needs. What I am unclear on is why it is not possible to support generic GATT and PB-GATT + Proxy Client/Server on the same controller. If PB-ADV is only used for provisioning then the time spent in ADV will not affect steady state operations. Thanks, Danielle On Tue, Dec 18, 2018 at 8:28 AM Gix, Brian <brian.gix@xxxxxxxxx> wrote: > > Hi Michal, > > > -----Original Message----- > > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Michal Lowas-Rzechonek > > Sent: Tuesday, December 18, 2018 3:09 AM > > To: linux-bluetooth@xxxxxxxxxxxxxxx > > Subject: Re: Plans for meshd > > > [...] > > What I'm thinking about is having both modes of communication available, > > even if the embedded device has just one Controller, as is the case with the > > majority of off-the-shelf platforms. > > > > The reason we want/need both BLE/GATT and Mesh on the same node has a > > lot to do with provisioning - at the moment we configure our networks using > > a mobile app, meaning we need devices to support PB-GATT. This is because > > Controllers present in mobile devices do not support Mesh natively, and we > > can't assume there is a GATT Proxy nearby, especially when configuring a > > new network. > > > > > And I am not opposed to someone starting a project that will allow the > > > bluetoothd and meshd share a single controller and taking > > > responsibility the reduced performance of each, but that is not work > > > we have planned. > > Ack. > > > > FYI, it seems we might be interested in making that happen. > > Maybe we should start with what you actually need. > * Do you need GATT support only for the Provisioning procedure? > * or also as a GATT proxy Server? > > There is a possibility... We had an internal project where we supported a GATT Proxy server without using the bluetooothd services at all. For bluetoothd, the result is the same: The controller was entirely under the control of the mesh executable (it was not a daemon, but a proof-of-concept command line tool). But there are problems with that particular idea given the architecture of the meshd daemon: > > * I do not think we should try to support Proxy Client *at all*. The Proxy Client assumes a single Node, which defeats the purpose of having a daemon at all. > > * Only a single node (or unprovisioned GATT server) can use GATT at a time. The protocol does not allow for the multi-node architecture of the daemon. > > * If we do try to put a GATT Proxy Server on a single controller implementation, we may need a special node that loops back data received from the Mesh to the Gatt Client. > > * We will probably need to limit this special GATT supporting node to a single node on the daemon. > > * We may want to make this a build-time option, because ADV handling will probably be affected whether an existing GATT connection is established or not, if it is possible that a GATT connection could be requested. > > * This affects the times when we can use Randomized, ever changing BD ADDRs, and requires us to interleave connectable advertisements and "be connectable", which is not technically allowed with mesh network ADV packets. > > > > > > > > regards > > -- > > Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> > > Silvair http://silvair.com > > Jasnogórska 44, 31-358 Krakow, POLAND -- - Danielle Costantino
