why does GATT use Characteristic

[SH]

Suppose I want my BT peripheral to provide Measured value of sensor X and Location of sensor.

Currently I have to send the following attributes

Service Attrinbute Characteristic attribute for measurement Attribute with actual measured value Characteristic attribute for location Attribute with actual location

Why do we need the Characteristic row? All the information in it seems redundant to me and and I can get all of the info by just looking at the columns of the Attribute with the actual value (e.g the three things in the value field of the Characteristic attribute

1. read/write/notify can be judged from Permission column of the attribute corresponding to the value,
2. UUID of measurement can be obtained from UUID column of the attribute corresponding to the value,
3. Handle from the Handle column of the attribute corresponding to the value,

Hence, it just seems meaningless overhead to me?

I am sure I'm missing something, so enlighten me! :)

[Ulrich Myhre]

This is purely due to how the core spec defines it, as you probably know :)

The characteristic declaration in the table exists mainly because it should be possible to discover the database layout and still keep the actual values locked by permission settings. GATT defines that all declarations should be readable, but the value handles can have varying permission settings through authorization or authentication.

A declaration itself also has its own UUID saying what it is (e.g. 0x2803 for characteristic), meaning it is possible to enumerate every (primary/secondary) service or every characteristic in relatively few messages. It would of course be possible to simply skip the declaration part and strip out the metadata once asked for it, but you would have to introduce some concept of "sub-UUIDs" to preserve the same functionality you have today.

[cocoa]

In BLE version 4.1 specifications was been introduced L2CAP Connection Oriented and Dedicated Channels, that might means a non-GATT profiles or other protocols in additions to ATT and SMP.

See this Nordic ULP and this on stackoverflow .

S130 soft device should be 4.1 compliant.

-c

[Ulrich Myhre]

It is actually optional to implement any of the new 4.1 features, meaning a 4.0 device with a few parameter tweaks would become "4.1 compliant" in a sense. So it's up to each vendor if they want to implement low duty cycle directed advertising, LL ping, L2CAP CoC, etc. Hoping to see the L2CAP communication in the future though!

[cocoa]

It would be interesting to have a comment about low duty cycle directed advertising, LL ping, L2CAP CoC, etc... by Nordic.