RE: Plans for meshd

["Gix, Brian" <brian.gix@intel.com>]

Hi Danielle,

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Danielle Costantino
> Sent: Tuesday, December 18, 2018 9:08 AM
> To: Gix, Brian <brian.gix@intel.com>
> Cc: michal.lowas-rzechonek@silvair.com; linux-bluetooth@vger.kernel.org
> Subject: Re: Plans for meshd
> 
> 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.

I am not entirely sure I understand your question, so I will answer the question I *think* you are asking.

Mesh is an Advertising based system, that works best in a steady state when everyone is just
passively scanning for connectionless advertising packets, and sending them when required.

GATT runs over an ACL connection which reserves a certain amount of the available "time" bandwidth, even when the ACL link is idle.  This reduces the opportunities for the controller to hear advertising packets, and there are more missed  mesh (ADV) packets as a result.

Also (with the possible exception of a higher speed Firmware update path) the  GATT Proxy Service is intended as a legacy method for a GATT Only device to join a mesh, and talk to node through the mesh.  It is *not* intended to be the main bearer of the mesh (i.e. all the nodes are *not* interconnected by GATT...   only the nodes that do not support discrete advertising control...  like perhaps older smartphones).

The "Backbone" of any Mesh Network will be ADV bearer only.


> Thanks,
> Danielle
> 
> On Tue, Dec 18, 2018 at 8:28 AM Gix, Brian <brian.gix@intel.com> wrote:
> >
> > Hi Michal,
> >
> > > -----Original Message-----
> > > From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> > > owner@vger.kernel.org] On Behalf Of Michal Lowas-Rzechonek
> > > Sent: Tuesday, December 18, 2018 3:09 AM
> > > To: linux-bluetooth@vger.kernel.org
> > > 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@silvair.com>
> > > Silvair http://silvair.com
> > > Jasnogórska 44, 31-358 Krakow, POLAND
> 
> 
> 
> --
> - Danielle Costantino