[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-bluetooth
Subject:    Re: [RFC] need for new scan api for bluetooth low energy.
From:       Jakub Pawlowski <jpawlowski () google ! com>
Date:       2014-09-30 21:11:59
Message-ID: CAD0=r8xDHvVq9QyCwo7_di_QRhbqEYdGJCKevQoEQ8WZRwA4dA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Sep 30, 2014 at 11:54 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Jakub,
> 
> > Ok, new updated version - we do only passive scan, and we send Device
> > found event:
> > 
> > 
> > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> > index 11e2490..3d03617 100644
> > --- a/doc/mgmt-api.txt
> > +++ b/doc/mgmt-api.txt
> > @@ -2135,6 +2135,29 @@ Set Public Address Command
> > Invalid Index
> > 
> > 
> > +Start Passive LE Filtered Device Scan
> > +=======================
> > +
> > +       Command Code:           0x003A
> > +       Controller Index:       <controller id>
> > +       Command Parameters:     UUID (16 Octets)
> > +                    max_pathloss (1 octet)
> > +
> > +       Return Parameters:
> > +
> > +       This command starts passive LE scan, and filter received
> > advertisements: if AD contains both TX power level and Service
> > Solicitation, and UUID is contained in Service Solicitation and
> > computed pathloss is smaller than max_pathloss parameter, then a
> > Device Found event will be sent.
> 
> generally we tried to avoid to specific LE only commands. Our attempts with the \
> kernel APIs where to make them as generic as possible. So I think something along \
> the lines of adding and removing UUID filters should be something we should target \
> at. 
> Add UUID Notification Filter
> ============================
> 
> Command Parameters:     Address_Type (1 Octet)
> UUID (16 Octets)
> Max_Pathloss (1 Octet)
> Return Parameters:      Address_Type (1 Octet)
> 
> 
> Remove UUID Notification Filter
> ===============================
> 
> Command Parameters:     Address_Type (1 Octet)
> UUID (16 Octets)
> Return Parameters:      Address_Type (1 Octet)
> 
> The Address_Type would be defined the same way as for Start Discovery command.
> 
> Now we can discuss if on the mgmt level we want to use pathloss or rather a range \
> of RSSI. I have seen that RSSI is preferred and that the translation from RSSI and \
> advertising data with TX power level is done in the daemon. So for kernel API it \
> might be better to expose RSSI range. 
> Besides a RSSI range, we might also want to allow giving a RSSI threshold that \
> defines how much the RSSI to change between events to be reported again.

Some mobile devices that I'm working can change power level for
advertising, that makes raw RSSI filter useless. It must be pathloss,
that's why I require TX power in advertisement.

> 
> That said, the danger with a generic notification filter like this is that we can \
> not implement it efficiently with current hardware without vendor commands. If you \
> use duplicate filtering, then Broadcom and CSR chips behave fully different. \
> Broadcom only filters on BD_ADDR and report devices once no matter what the RSSI, \
> while CSR will report the same device again if the RSSI changes. 
> With that in mind, it might be safer to introduce a one-shot mgmt API that needs to \
> be repeatedly called to keep scanning for new devices. 
> Start Service Discovery
> =======================
> 
> Command Parameters:     Address_Type (1 Octet)
> Min_RSSI (1 Octet)
> Max_RSSI (1 Octet)
> Num_UUID (1 Octet)
> UUID[i] (16 Octets)
> Return Parameters:      Address_Type (1 Octet)
> 
> Stop Service Discovery
> ======================
> 
> Command Parameters:     Address_Type (1 Octet)
> Return Parameters:      Address_Type (1 Octet)
> 
> Without having dedicated controller support for filtering, having such a dedicated \
> discovery for services with a specific UUID seems to be more appropriate and more \
> safe. Since we could always add controller based filtering for background scanning \
> once there is controller support.

I preffer the "Add UUID Notification Filter" and "Remove UUID
Notification Filter". For controllers like Broadcom that reports only
one advertisement can we restart scan internally in kernel ? Why
propagate that event higher ?


> 
> Regards
> 
> Marcel
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]