[RFC] LE connections and advertising management

[RFC] LE connections and advertising management

[Claudio Takahasi]

Hi all,

Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.

Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a  way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.


Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received

An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel

Comments?

Regards,
Claudio

Re: [RFC] LE connections and advertising management

[Anderson Lizardo]

On Mon, Oct 25, 2010 at 8:53 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> 4. Kernel manages the connection establishment, currently there isn't
> a  way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.

Another idea would be to use setsockopt(), like it's currently being
used for HCI filters (see lib/hci.c). E.g.:

hci_filter_clear(&nf);
hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
hci_filter_set_event(EVT_LE_META_EVENT, &nf);
setsockopt(dd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf);

Not sure if the SMP negotiation happens too soon to use it though.

Regards,
-- 
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil

RE: [RFC] LE connections and advertising management

[Mike Tsai]

-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
Sent: Monday, October 25, 2010 5:53 AM
To: BlueZ development
Subject: [RFC] LE connections and advertising management

Hi all,

Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.

Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a  way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.


Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received

An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel

Comments?

Regards,
Claudio
>>MT comments,

1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events

>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?

4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only

>> You mean both characteristic value and characteristic descriptors of characteristic?

Regards,

Mike

--
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

Re: [RFC] LE connections and advertising management

[Claudio Takahasi]

On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a  way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.

>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.

Regards,
Claudio
>
> Regards,
>
> Mike
>
> --
> 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
>

RE: [RFC] LE connections and advertising management

[Mike Tsai]

-----Original Message-----
From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org] 
Sent: Monday, October 25, 2010 10:56 AM
To: Mike Tsai
Cc: BlueZ development
Subject: Re: [RFC] LE connections and advertising management

On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a  way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.
[Mike Tsai]
I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?

>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.
[Mike Tsai]
Yes, I will really appreciate if you may show me the planned API for this GAttrib,


Regards,
Claudio
>
> Regards,
>
> Mike
>
> --
> 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
>

Re: [RFC] LE connections and advertising management

[Claudio Takahasi]

On Mon, Oct 25, 2010 at 3:16 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
>
> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 10:56 AM
> To: Mike Tsai
> Cc: BlueZ development
> Subject: Re: [RFC] LE connections and advertising management
>
> On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
>> Sent: Monday, October 25, 2010 5:53 AM
>> To: BlueZ development
>> Subject: [RFC] LE connections and advertising management
>>
>> Hi all,
>>
>> Interleave BR/EDR/LE discovery is implemented, the next step in the
>> user space is how to manage advertising and LE connections.
>>
>> Some aspects:
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>> 2. The remote/Peripheral can support more than one GATT primary service
>> 3. We are planning to use "direct" connections only, meaning that we
>> will not use whitelist and the application interested must inform the
>> remote address/object to connect to.
>> 4. Kernel manages the connection establishment, currently there isn't
>> a  way to change the connection parameters. BMI or ioctls will be
>> required to change the default parameters and also to trigger SMP
>> negotiation.
>>
>>
>> Some ideas:
>> 1. implement a characteristic driver: basically to provide an
>> abstraction to GATT clients. ex: Proximity, Health, ...
>> 2. We don't need to implement Proximity and other GATT clients as a
>> plugin at the moment, it can be enabled automatically by
>> --enable-attrib
>> 3. GATT clients could register a watcher/filter for advertising events
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>> 5. GATT clients needs to control/request LE connections based on the
>> advertisement received
>>
>> An initial draft implementing part of this idea is here:
>> git://git.infradead.org/users/cktakahasi/bluez.git devel
>>
>> Comments?
>>
>> Regards,
>> Claudio
>>>>MT comments,
>>
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>>
>>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
> [Claudio Takahasi]
> The master can be connected to more than one slave. But here, I wanna
> emphasize that only one instance of GAtttrib shall be created to
> represent the physical channel between two LE capable devices. GAttrib
> is the abstraction that we created in BlueZ to represent the GATT/ATT
> connection, it is necessary to address multiple applications/profiles
> and queue commands/events.
> [Mike Tsai]
> I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
> May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?
[Claudio Takahasi]
Hi Mike,

At the moment it is not clear to me if an "application handle" will be
needed, maybe we can also hide it from the higher layers. All requests
are serialized and for each request there is a response, the
exceptions are write without response and notification. Each primary
service representation will have an object path, meaning that maybe it
is possible forward the response to the right source based on the last
request and handle information.

GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
clients services using D-Bus.
GATT clients in general will have two pieces:
 1- UI: Qt, GTK, python, ...
 2- "module" in the BlueZ for profile specific tasks and D-Bus service
interface.

You can find the current attribute API in the file: doc/attribute-api.txt

Claudio

>
>>
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>>
>>>> You mean both characteristic value and characteristic descriptors of characteristic?
> [Claudio Takahasi]
> Both. For the GATT client role, an interface can be created exporting
> profile specific details.
> Sometimes GATT clients will also need to access some low level information.
> [Mike Tsai]
> Yes, I will really appreciate if you may show me the planned API for this GAttrib,
>
>
> Regards,
> Claudio
>>
>> Regards,
>>
>> Mike
>>
>> --
>> 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
>>
>



-- 
--
Claudio Takahasi
Instituto Nokia de Tecnologia
Recife - Pernambuco - Brasil
+55 81 30879999

RE: [RFC] LE connections and advertising management

[Brian Redding]

> GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
> clients services using D-Bus.
> GATT clients in general will have two pieces:
> 1- UI: Qt, GTK, python, ...
> 2- "module" in the BlueZ for profile specific tasks and D-Bus service
> interface.

> You can find the current attribute API in the file: doc/attribute-api.txt

> Claudio

Hi Claudio,

Are there still interfaces that need to be added to attribute-api.txt to handle client and server characteristic configuration as well as presentation and aggregate formats?  I see those as TODO items but wondered if the APIs for them have been defined yet.

One thing to note on the server API is that a GATT-based profile could specify behavior on a characteristic value that when the characteristic value is read to perform some action in a similar way as a hardware register.  It appears that the notes I'm reading in the code thus far only consider changes (or writes) to characteristic values for the watch code.

Also does the current API handle included services?

The Bluetooth SIG is beginning to look at 3rd party application developer API's for both client and servers for various platforms so understanding what is currently defined in BlueZ and what still needs to be added would be useful.

Thanks,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: [RFC] LE connections and advertising management

[Claudio Takahasi]

Hi Brian,

On Mon, Oct 25, 2010 at 4:27 PM, Brian Redding <bredding@codeaurora.org> wrote:
> Hi Claudio,
>
> Are there still interfaces that need to be added to attribute-api.txt to handle client and server characteristic configuration as well as presentation and aggregate formats?  I see those as TODO items but wondered if the APIs for them have been defined yet.
>
> One thing to note on the server API is that a GATT-based profile could specify behavior on a characteristic value that when the characteristic value is read to perform some action in a similar way as a hardware register.  It appears that the notes I'm reading in the code thus far only consider changes (or writes) to characteristic values for the watch code.
>
> Also does the current API handle included services?
>
> The Bluetooth SIG is beginning to look at 3rd party application developer API's for both client and servers for various platforms so understanding what is currently defined in BlueZ and what still needs to be added would be useful.
>
> Thanks,
> Brian
> ---
> Brian A. Redding
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

The API to address characteristic descriptors is still being defined.
We are focusing in the advertising and connection management at the
moment. If you have suggestion of how to represent the descriptors in
the attribute API, suggestions are welcome!

There isn't a server API at the moment, we implemented a server for
testing purpose only. But we will need to define it soon.
Which pages/section of the spec describes this read characteristic behavior?

Included services are not supported by our client. How important is
it? It is mandatory for qualification?

Regards,
Claudio.

RE: [RFC] LE connections and advertising management

[Brian Redding]

> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 9:52 PM
> 
> Hi Brian,
> 
> On Mon, Oct 25, 2010 at 4:27 PM, Brian Redding
> <bredding@codeaurora.org> wrote:
> > Hi Claudio,
> >
> > Are there still interfaces that need to be added to attribute-api.txt
> > to handle client and server characteristic configuration as well as
> > presentation and aggregate formats?  I see those as TODO items but
> > wondered if the APIs for them have been defined yet.
> >
> > One thing to note on the server API is that a GATT-based profile
> > could specify behavior on a characteristic value that when the
> > characteristic value is read to perform some action in a similar way as
> > a hardware register.  It appears that the notes I'm reading in the code
> > thus far only consider changes (or writes) to characteristic values for
> > the watch code.
> >
> > Also does the current API handle included services?
> >
> > The Bluetooth SIG is beginning to look at 3rd party application
> > developer API's for both client and servers for various platforms so
> > understanding what is currently defined in BlueZ and what still needs
> > to be added would be useful.
> >
> > Thanks,
> > Brian
> 
> The API to address characteristic descriptors is still being defined.
> We are focusing in the advertising and connection management at the
> moment. If you have suggestion of how to represent the descriptors in
> the attribute API, suggestions are welcome!

Once I feel more comfortable with the current API approach, I will see
if I can suggest something.  One thing to note is that GATT only list
the current characteristic descriptors.  Profiles can specify additional
ones or a group of generic ones could also be adopted in the future.
One example of this is a characteristic descriptor that defines triggers
that cause a particular behavior to occur when a condition on the characteristic
value occurs.

> 
> There isn't a server API at the moment, we implemented a server for
> testing purpose only. But we will need to define it soon.
> Which pages/section of the spec describes this read characteristic
> behavior?

The GATT does not specify the read characteristic behavior but it can be
specified by a profile.  I just wanted to point that out so that the design
takes that into account.  You may need to have a call back when a characteristic
value is read as well as written.

> 
> Included services are not supported by our client. How important is
> it? It is mandatory for qualification?

It is only mandatory on the server.

> 
> Regards,
> Claudio.

Cheers,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

RE: [RFC] LE connections and advertising management

[Mike Tsai]

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0
bzpjbGF1ZGlvLnRha2FoYXNpQG9wZW5ib3NzYS5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVy
IDI1LCAyMDEwIDExOjU1IEFNDQpUbzogTWlrZSBUc2FpDQpDYzogQmx1ZVogZGV2ZWxvcG1lbnQN
ClN1YmplY3Q6IFJlOiBbUkZDXSBMRSBjb25uZWN0aW9ucyBhbmQgYWR2ZXJ0aXNpbmcgbWFuYWdl
bWVudA0KDQpPbiBNb24sIE9jdCAyNSwgMjAxMCBhdCAzOjE2IFBNLCBNaWtlIFRzYWkgPE1pa2Uu
VHNhaUBhdGhlcm9zLmNvbT4gd3JvdGU6DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+IEZyb206IENsYXVkaW8gVGFrYWhhc2kgW21haWx0bzpjbGF1ZGlvLnRha2FoYXNpQG9w
ZW5ib3NzYS5vcmddDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCAxMDo1NiBBTQ0K
PiBUbzogTWlrZSBUc2FpDQo+IENjOiBCbHVlWiBkZXZlbG9wbWVudA0KPiBTdWJqZWN0OiBSZTog
W1JGQ10gTEUgY29ubmVjdGlvbnMgYW5kIGFkdmVydGlzaW5nIG1hbmFnZW1lbnQNCj4NCj4gT24g
TW9uLCBPY3QgMjUsIDIwMTAgYXQgMjoxMSBQTSwgTWlrZSBUc2FpIDxNaWtlLlRzYWlAYXRoZXJv
cy5jb20+IHdyb3RlOg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBsaW51eC1ibHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtYmx1
ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIENsYXVkaW8gVGFrYWhh
c2kNCj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAxMCA1OjUzIEFNDQo+PiBUbzogQmx1
ZVogZGV2ZWxvcG1lbnQNCj4+IFN1YmplY3Q6IFtSRkNdIExFIGNvbm5lY3Rpb25zIGFuZCBhZHZl
cnRpc2luZyBtYW5hZ2VtZW50DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IEludGVybGVhdmUgQlIv
RURSL0xFIGRpc2NvdmVyeSBpcyBpbXBsZW1lbnRlZCwgdGhlIG5leHQgc3RlcCBpbiB0aGUNCj4+
IHVzZXIgc3BhY2UgaXMgaG93IHRvIG1hbmFnZSBhZHZlcnRpc2luZyBhbmQgTEUgY29ubmVjdGlv
bnMuDQo+Pg0KPj4gU29tZSBhc3BlY3RzOg0KPj4gMS4gT25seSBvbmUgTEUgY29ubmVjdGlvbiBp
cyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0dHJpYiBpbnN0YW5j
ZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvDQo+
PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+PiAyLiBUaGUgcmVtb3RlL1BlcmlwaGVyYWwg
Y2FuIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBHQVRUIHByaW1hcnkgc2VydmljZQ0KPj4gMy4gV2Ug
YXJlIHBsYW5uaW5nIHRvIHVzZSAiZGlyZWN0IiBjb25uZWN0aW9ucyBvbmx5LCBtZWFuaW5nIHRo
YXQgd2UNCj4+IHdpbGwgbm90IHVzZSB3aGl0ZWxpc3QgYW5kIHRoZSBhcHBsaWNhdGlvbiBpbnRl
cmVzdGVkIG11c3QgaW5mb3JtIHRoZQ0KPj4gcmVtb3RlIGFkZHJlc3Mvb2JqZWN0IHRvIGNvbm5l
Y3QgdG8uDQo+PiA0LiBLZXJuZWwgbWFuYWdlcyB0aGUgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50
LCBjdXJyZW50bHkgdGhlcmUgaXNuJ3QNCj4+IGEgwqB3YXkgdG8gY2hhbmdlIHRoZSBjb25uZWN0
aW9uIHBhcmFtZXRlcnMuIEJNSSBvciBpb2N0bHMgd2lsbCBiZQ0KPj4gcmVxdWlyZWQgdG8gY2hh
bmdlIHRoZSBkZWZhdWx0IHBhcmFtZXRlcnMgYW5kIGFsc28gdG8gdHJpZ2dlciBTTVANCj4+IG5l
Z290aWF0aW9uLg0KPj4NCj4+DQo+PiBTb21lIGlkZWFzOg0KPj4gMS4gaW1wbGVtZW50IGEgY2hh
cmFjdGVyaXN0aWMgZHJpdmVyOiBiYXNpY2FsbHkgdG8gcHJvdmlkZSBhbg0KPj4gYWJzdHJhY3Rp
b24gdG8gR0FUVCBjbGllbnRzLiBleDogUHJveGltaXR5LCBIZWFsdGgsIC4uLg0KPj4gMi4gV2Ug
ZG9uJ3QgbmVlZCB0byBpbXBsZW1lbnQgUHJveGltaXR5IGFuZCBvdGhlciBHQVRUIGNsaWVudHMg
YXMgYQ0KPj4gcGx1Z2luIGF0IHRoZSBtb21lbnQsIGl0IGNhbiBiZSBlbmFibGVkIGF1dG9tYXRp
Y2FsbHkgYnkNCj4+IC0tZW5hYmxlLWF0dHJpYg0KPj4gMy4gR0FUVCBjbGllbnRzIGNvdWxkIHJl
Z2lzdGVyIGEgd2F0Y2hlci9maWx0ZXIgZm9yIGFkdmVydGlzaW5nIGV2ZW50cw0KPj4gNC4gR0FU
VCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhlb3J5IGl0IGNhbiBoYW5k
bGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+PiA1LiBHQVRUIGNsaWVudHMgbmVlZHMgdG8g
Y29udHJvbC9yZXF1ZXN0IExFIGNvbm5lY3Rpb25zIGJhc2VkIG9uIHRoZQ0KPj4gYWR2ZXJ0aXNl
bWVudCByZWNlaXZlZA0KPj4NCj4+IEFuIGluaXRpYWwgZHJhZnQgaW1wbGVtZW50aW5nIHBhcnQg
b2YgdGhpcyBpZGVhIGlzIGhlcmU6DQo+PiBnaXQ6Ly9naXQuaW5mcmFkZWFkLm9yZy91c2Vycy9j
a3Rha2FoYXNpL2JsdWV6LmdpdCBkZXZlbA0KPj4NCj4+IENvbW1lbnRzPw0KPj4NCj4+IFJlZ2Fy
ZHMsDQo+PiBDbGF1ZGlvDQo+Pj4+TVQgY29tbWVudHMsDQo+Pg0KPj4gMS4gT25seSBvbmUgTEUg
Y29ubmVjdGlvbiBpcyBhbGxvd2VkKHBlciBwZWVyKSwgbWVhbmluZyBvbmx5IG9uZQ0KPj4gR0F0
dHJpYiBpbnN0YW5jZSB3aWxsIGJlIGFsbG93ZWQgb3RoZXJ3aXNlIGl0IHdpbGwgbm90IGJlIHBv
c3NpYmxlIHRvDQo+PiBzZXJpYWxpemUgY29tbWFuZHMvZXZlbnRzDQo+Pg0KPj4+PiBZb3UgbWVh
biB0aGUgbWFzdGVyIChvciBjbGllbnQpIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBzbGF2ZSAob3Ig
c2VydmVyKSBvciBhIHNsYXZlIGNhbiBvbmx5IGNvbm5lY3QgdG8gMSBtYXN0ZXI/DQo+IFtDbGF1
ZGlvIFRha2FoYXNpXQ0KPiBUaGUgbWFzdGVyIGNhbiBiZSBjb25uZWN0ZWQgdG8gbW9yZSB0aGFu
IG9uZSBzbGF2ZS4gQnV0IGhlcmUsIEkgd2FubmENCj4gZW1waGFzaXplIHRoYXQgb25seSBvbmUg
aW5zdGFuY2Ugb2YgR0F0dHRyaWIgc2hhbGwgYmUgY3JlYXRlZCB0bw0KPiByZXByZXNlbnQgdGhl
IHBoeXNpY2FsIGNoYW5uZWwgYmV0d2VlbiB0d28gTEUgY2FwYWJsZSBkZXZpY2VzLiBHQXR0cmli
DQo+IGlzIHRoZSBhYnN0cmFjdGlvbiB0aGF0IHdlIGNyZWF0ZWQgaW4gQmx1ZVogdG8gcmVwcmVz
ZW50IHRoZSBHQVRUL0FUVA0KPiBjb25uZWN0aW9uLCBpdCBpcyBuZWNlc3NhcnkgdG8gYWRkcmVz
cyBtdWx0aXBsZSBhcHBsaWNhdGlvbnMvcHJvZmlsZXMNCj4gYW5kIHF1ZXVlIGNvbW1hbmRzL2V2
ZW50cy4NCj4gW01pa2UgVHNhaV0NCj4gSSBzZWUuIEluIG9yZGVyIHRvIGhhbmRsZSBtdWx0aXBs
ZSBwcm9maWxlcyAoYXMgbXVsdGlwbGUgYXBwbGljYXRpb25zIHJ1bm5pbmcgb24gdG9wIG9mIHRo
ZSBHQXR0cmliKSBpbiBhIHNpbmdsZSBwaHlzaWNhbCBsaW5rLCB5b3Ugd2lsbCBuZWVkIHNvbWV0
aGluZyBsaWtlICJhcHBsaWNhdGlvbiBoYW5kbGUiIHRvIGRpc3BhdGNoIHRoZSByZXNwb25zZS9p
ZGVudGlmaWNhdGlvbiB0byB0aGUgYXBwcm9wcmlhdGUgYXBwbGljYXRpb24gY29ycmVjdGx5Lg0K
PiBNYXkgeW91IHJlZmVyIG1lIHRvIHRoZSBBUEkgZG9jdW1lbnQgdGhhdCB5b3UgYXJlIG9wZW5p
bmcgdG8gdGhlIEdBVFQgY2xpZW50KHMpIGZyb20gdGhpcyBHQXR0cmliPw0KW0NsYXVkaW8gVGFr
YWhhc2ldDQpIaSBNaWtlLA0KDQpBdCB0aGUgbW9tZW50IGl0IGlzIG5vdCBjbGVhciB0byBtZSBp
ZiBhbiAiYXBwbGljYXRpb24gaGFuZGxlIiB3aWxsIGJlDQpuZWVkZWQsIG1heWJlIHdlIGNhbiBh
bHNvIGhpZGUgaXQgZnJvbSB0aGUgaGlnaGVyIGxheWVycy4gQWxsIHJlcXVlc3RzDQphcmUgc2Vy
aWFsaXplZCBhbmQgZm9yIGVhY2ggcmVxdWVzdCB0aGVyZSBpcyBhIHJlc3BvbnNlLCB0aGUNCmV4
Y2VwdGlvbnMgYXJlIHdyaXRlIHdpdGhvdXQgcmVzcG9uc2UgYW5kIG5vdGlmaWNhdGlvbi4gRWFj
aCBwcmltYXJ5DQpzZXJ2aWNlIHJlcHJlc2VudGF0aW9uIHdpbGwgaGF2ZSBhbiBvYmplY3QgcGF0
aCwgbWVhbmluZyB0aGF0IG1heWJlIGl0DQppcyBwb3NzaWJsZSBmb3J3YXJkIHRoZSByZXNwb25z
ZSB0byB0aGUgcmlnaHQgc291cmNlIGJhc2VkIG9uIHRoZSBsYXN0DQpyZXF1ZXN0IGFuZCBoYW5k
bGUgaW5mb3JtYXRpb24uDQoNCkdBdHRyaWIgd2lsbCBub3QgYmUgZXhwb3NlZCB0byB0aGUgVUku
IFVJIG5lZWRzIHRvIGFjY2VzcyBCbHVlWiBHQVRUDQpjbGllbnRzIHNlcnZpY2VzIHVzaW5nIEQt
QnVzLg0KR0FUVCBjbGllbnRzIGluIGdlbmVyYWwgd2lsbCBoYXZlIHR3byBwaWVjZXM6DQogMS0g
VUk6IFF0LCBHVEssIHB5dGhvbiwgLi4uDQogMi0gIm1vZHVsZSIgaW4gdGhlIEJsdWVaIGZvciBw
cm9maWxlIHNwZWNpZmljIHRhc2tzIGFuZCBELUJ1cyBzZXJ2aWNlDQppbnRlcmZhY2UuDQoNCllv
dSBjYW4gZmluZCB0aGUgY3VycmVudCBhdHRyaWJ1dGUgQVBJIGluIHRoZSBmaWxlOiBkb2MvYXR0
cmlidXRlLWFwaS50eHQNCg0KQ2xhdWRpbw0KDQpbTWlrZSBUc2FpXQ0KSGkgQ2xhdWRpbywNCg0K
CUkgbG9vayBhdCB0aGUgQVBJIGFuZCBpdCBpcyB3ZWxsLWRlZmluZWQgd2l0aCBoaWdoIGxldmVs
IG9mIGFic3RyYWN0aW9uLiBIb3dldmVyLCBJIGRpZCBoYXZlIGEgZmV3IHF1ZXN0aW9ucyBoZXJl
LCBob3BlZnVsbHkgeW91IGNhbiBhbnN3ZXIgdGhlbSwNCg0KCU9uIENsaWVudCBzaWRlOg0KDQoJ
CTEuIEkgc2VlIHlvdSBkaWRuJ3Qgb2ZmZXIgYW55IHNlcnZpY2UgZGlzY292ZXJ5IEFQSSBmb3Ig
Y2xpZW50IHRvIGRpc2NvdmVyIHRoZSBzZXJ2ZXIgc2VydmljZSBkYXRhYmFzZSAoYmFzaWNhbGx5
IHRvIGdldCB0aGUgYXR0cmlidXRlIGhhbmRsZXMpLiBTbyBJIGFzc3VtZSB0aGF0IHlvdSBjb25z
aWRlciBHQVRUIGRpc2NvdmVyeSBwcm9jZWR1cmUgd29ya3MgdGhlIHNhbWUgd2F5IGFzIFNEUCwg
ZG9uZSBhdXRvbWF0aWNhbGx5IGJ5IEdBVFQgYWZ0ZXIgbGluayBpcyBlc3RhYmxpc2hlZCB3aXRo
b3V0IGFwcGxpY2F0aW9uJ3MgaW5pdGlhdGl2ZS4gQW0gSSBjb3JyZWN0Pw0KDQoJCTIuIFRoZSBj
aGFyYWN0ZXJpc3RpYyBkZXNjcmlwdG9yIHNldCB2aWEgU2V0UHJvcGVydHkgQVBJIGlzIGxpbWl0
ZWQgdG8gdGhlIDYgY2hhcmFjdGVyaXN0aWMgZGVzY3JpcHRvcnMgZGVmaW5lZCBpbiBHQVRUIHNw
ZWMuIEhvd2V2ZXIsIHRoZXJlIGNvdWxkIGJlIHByb2ZpbGUgc3BlY2lmaWMgY2hhcmFjdGVyaXN0
aWMgZGVzY3JpcHRvcnMgYmV5b25kIHRoZXNlLCB3aWxsIHRoZSBTZXRQcm9wZXJ0eSBhYmxlIHRv
IHN1cHBvcnQgdGhlc2U/DQoNCgkJMy4gVGhlIGNoYXJhY3RlcmlzdGljIG1vbml0b3JpbmcgaXMg
c2V0IHVwIHZpYSAxMjggYml0cyBVVUlELiBEbyB5b3UgaGF2ZSBtZWNoYW5pc20gdG8gaGFuZGxl
IGR1cGxpY2F0ZWQgY2hhcmFjdGVyaXN0aWMgd2l0aGluIGEgc2VydmVyJ3MgZGF0YWJhc2U/IEhv
dyBkbyB5b3UgaWRlbnRpZnkgdGhlbSB2aWEgeW91ciBBUEk/DQoNCg0KCU9uIFNlcnZlciBzaWRl
Og0KDQoJCTEuIElzIHRoZXJlIGFuIEFQSSB0aGF0IGFsbG93cyBzZXJ2ZXIgYXBwbGljYXRpb24g
dG8gcmVnaXN0ZXIgbmV3IGF0dHJpYnV0ZXM/IChwcmltYXJ5IHNlcnZpY2UsIGNoYXJhY3Rlcmlz
dGljLCBpbmNsdWRlZCBzZXJ2aWNlLCBldCBhbCksDQoNClJlZ2FyZHMsDQoNCk1pa2UNCg0KDQo+
DQo+Pg0KPj4gNC4gR0FUVCBjbGllbnRzIGRvZXNuJ3QgbmVlZCB0byBrbm93IEFUVCwgaW4gdGhl
b3J5IGl0IGNhbiBoYW5kbGUNCj4+IGNoYXJhY3RlcmlzdGljcyBvbmx5DQo+Pg0KPj4+PiBZb3Ug
bWVhbiBib3RoIGNoYXJhY3RlcmlzdGljIHZhbHVlIGFuZCBjaGFyYWN0ZXJpc3RpYyBkZXNjcmlw
dG9ycyBvZiBjaGFyYWN0ZXJpc3RpYz8NCj4gW0NsYXVkaW8gVGFrYWhhc2ldDQo+IEJvdGguIEZv
ciB0aGUgR0FUVCBjbGllbnQgcm9sZSwgYW4gaW50ZXJmYWNlIGNhbiBiZSBjcmVhdGVkIGV4cG9y
dGluZw0KPiBwcm9maWxlIHNwZWNpZmljIGRldGFpbHMuDQo+IFNvbWV0aW1lcyBHQVRUIGNsaWVu
dHMgd2lsbCBhbHNvIG5lZWQgdG8gYWNjZXNzIHNvbWUgbG93IGxldmVsIGluZm9ybWF0aW9uLg0K
PiBbTWlrZSBUc2FpXQ0KPiBZZXMsIEkgd2lsbCByZWFsbHkgYXBwcmVjaWF0ZSBpZiB5b3UgbWF5
IHNob3cgbWUgdGhlIHBsYW5uZWQgQVBJIGZvciB0aGlzIEdBdHRyaWIsDQo+DQo+DQo+IFJlZ2Fy
ZHMsDQo+IENsYXVkaW8NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IE1pa2UNCj4+DQo+PiAtLQ0K
Pj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2Ny
aWJlIGxpbnV4LWJsdWV0b290aCIgaW4NCj4+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpv
cmRvbW9Admdlci5rZXJuZWwub3JnDQo+PiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0IMKgaHR0cDov
L3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+Pg0KPg0KDQoNCg0KLS0gDQot
LQ0KQ2xhdWRpbyBUYWthaGFzaQ0KSW5zdGl0dXRvIE5va2lhIGRlIFRlY25vbG9naWENClJlY2lm
ZSAtIFBlcm5hbWJ1Y28gLSBCcmFzaWwNCis1NSA4MSAzMDg3OTk5OQ0K

Re: [RFC] LE connections and advertising management

[Claudio Takahasi]

Hi Mike,

On Tue, Oct 26, 2010 at 6:10 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> [Mike Tsai]
> Hi Claudio,
>
>        I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them,
>
>        On Client side:
>
>                1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct?
>
>                2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these?
>
>                3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API?
>
>
>        On Server side:
>
>                1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al),
>
> Regards,
>
> Mike

Client side:
Yes. ALL characteristics are fetched after "create the device"
procedure.  This approach is wrong, some characteristics requires
encryption, authentication or authorization. Another aspect is that we
need to avoid excessive transactions. The idea now is try to search
for the primary service information only and "probe" the clients that
match with the registered service UUID. When "probed" the clients will
receive the GAttrib instance and the primary service handles range. It
is up to them to decide which attributes are relevant. Note that the
clients are only another "layer" implementing profile specific
features inside BlueZ.

It is a little bit unclear to me at the moment, but we can expose
Profile specific features. Such as threshold, alert level, ...

Is it allowed duplicated UUIDs for the same primary service? We are
not handling this right now.
It seems that you already have a proprietary implementation ;-)

Server side:
No API. We wrote an attribute server for testing purpose only. But we
will address this soon.

Regards,
Claudio

RE: [RFC] LE connections and advertising management

[Mike Tsai]

Hi Claudio,

-----Original Message-----
From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org] 
Sent: Tuesday, October 26, 2010 6:02 PM
To: Mike Tsai
Cc: BlueZ development
Subject: Re: [RFC] LE connections and advertising management

Hi Mike,

On Tue, Oct 26, 2010 at 6:10 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> [Mike Tsai]
> Hi Claudio,
>
>        I look at the API and it is well-defined with high level of abstraction. However, I did have a few questions here, hopefully you can answer them,
>
>        On Client side:
>
>                1. I see you didn't offer any service discovery API for client to discover the server service database (basically to get the attribute handles). So I assume that you consider GATT discovery procedure works the same way as SDP, done automatically by GATT after link is established without application's initiative. Am I correct?
>
>                2. The characteristic descriptor set via SetProperty API is limited to the 6 characteristic descriptors defined in GATT spec. However, there could be profile specific characteristic descriptors beyond these, will the SetProperty able to support these?
>
>                3. The characteristic monitoring is set up via 128 bits UUID. Do you have mechanism to handle duplicated characteristic within a server's database? How do you identify them via your API?
>
>
>        On Server side:
>
>                1. Is there an API that allows server application to register new attributes? (primary service, characteristic, included service, et al),
>
> Regards,
>
> Mike

Client side:
Yes. ALL characteristics are fetched after "create the device"
procedure.  This approach is wrong, some characteristics requires
encryption, authentication or authorization. Another aspect is that we
need to avoid excessive transactions. The idea now is try to search
for the primary service information only and "probe" the clients that
match with the registered service UUID. When "probed" the clients will
receive the GAttrib instance and the primary service handles range. It
is up to them to decide which attributes are relevant. Note that the
clients are only another "layer" implementing profile specific
features inside BlueZ.

[Mike Tsai]Thanks for the detailed info, I know understand more about your architecture approach. More questions below:

	1. So these "clients" (profiles) will be below d-bus and linked directly with GAttrib?

	2. Will these clients cache the discovered attribute handles that it is interested in and respond to "service change" event sent by server? Since we really want to limit the attribute handle discovery only once (same as pairing).

	3. Will these clients check the security (attribute permission) for each characteristic too?  

It is a little bit unclear to me at the moment, but we can expose
Profile specific features. Such as threshold, alert level, ...
[Mike Tsai] Yes, perhaps need to open up the characteristic descriptor for client to register with GAttrib so GAttrib knows to forward to client same as existing 6 characteristic descriptors.

Is it allowed duplicated UUIDs for the same primary service? We are
not handling this right now.
It seems that you already have a proprietary implementation ;-)

[Mike Tsai] I think it is probably not allowed to duplicate characteristic within the same primary services. However, there may be duplicated primary services within a server or duplicated included service within a server, or same characteristic inside 2 different primary services. So I don't know if you have any mechanism to let GAttrib get the correct characteristic within all these duplicated services by just passing the 128 bits UUID?

Server side:
No API. We wrote an attribute server for testing purpose only. But we
will address this soon.

Regards,
Claudio

RE: [RFC] LE connections and advertising management

[Brian Redding]

> [Claudio]
> Is it allowed duplicated UUIDs for the same primary service? We are
> not handling this right now.
> It seems that you already have a proprietary implementation ;-)
> 
> [Mike Tsai] I think it is probably not allowed to duplicate
> characteristic within the same primary services. However, there may be
> duplicated primary services within a server or duplicated included
> service within a server, or same characteristic inside 2 different
> primary services. So I don't know if you have any mechanism to let
> GAttrib get the correct characteristic within all these duplicated
> services by just passing the 128 bits UUID?

The GATT places no limitation on multiple instances of characteristics or
services.  The recommendation to profile writers when duplicate
characteristics exist within a service is that each characteristic has a
characteristic presentation descriptor that distinguishes each instance of
the characteristic.  The same would apply to multiple instances of a
service.  There are other methods to distinguish multiple instances of
services and characteristics including different UUIDs so there isn't a
single approach.  The approach though is specified by the profile.

Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum