How to increase number of characteristics

RE: How to increase number of characteristics

endnode — Wed, 30 Sep 2015 14:17:54 GMT

You are right, BT SIG don't mandate grouping 128-bit UUIDs by any base for Service and its Characteristics, it's just the routine.

RE: How to increase number of characteristics

Tim — Wed, 30 Sep 2015 12:55:29 GMT

I've not read that anywhere - and actually it worked with every service and characteristic having totally different base UUIDs (up to the limit of 8). However in my code I now use the same base UUID for everything.

RE: How to increase number of characteristics

endnode — Wed, 30 Sep 2015 11:39:48 GMT

And btw. if you start to care really about security (which I hope all the people involved in IoT will soon!) then you encounter problems such as anonymity through tracking of MAC addresses (Adv. Address in case of BLE GAP Peripheral role). This is already problem with classic BT and Wifi and some manufactures (e.g. iOS) already started to randomize these things (at least a bit - e.g. with long rotation period but but better then nothing). Now if you project this into BLE I believe you see where it is going (and why it is again more interesting to use "minimal" part of BLE stack as "tube" and do clever things on applicative layer - unless you design really largely interoperable schemes such as new GAP profile which should work on various devices from multiple vendors or you are designing new IoT protocol which should be widely adopted and coexist with current GAP profiles).

RE: How to increase number of characteristics

endnode — Wed, 30 Sep 2015 11:33:02 GMT

Re discovery procedure: you are right, if stack on peripheral side is static (+ does not provide "Service Changed Characteristic") it's good chance that central stack will cache it (link it to Adv. Address). However this is not perfect because also central stack is some sort of embedded device so it cannot log all the addresses, it is also usually out of your control (e.g. in the mobile phone or similar rich OS platform) so you never know if and how well it does this caching (it can decide to delete "old" records randomly or based on time or just during OS upgrade...) So in general there are catches and if you claim that in your special case it will work (which I'm perfectly fine and in-line) then it leads back to my original remark: why to make it so "general" and complex when in the end it will be just your proprietary protocol between one "peripheral" and dedicated "central app"?

RE: How to increase number of characteristics

endnode — Wed, 30 Sep 2015 11:26:05 GMT

Re Security: there is actually only one mode which is really secure in BT SIG 4.0&4.1 defined for LE: OOB (Out-Of-Bend). There you distribute the keys yourself (e.g. derive from static master key known to all parts or transported by other media such as keyboard or NFC). With fix in spec 4.2 which brings asymmetric bootstrapping with ECC it makes some sense to use "native" security layer provided by LE stack but it isn't really adopted yet. In addition to the scaling: most of the implementations (e.g. all SoftDevices from Nordic) are limiting number of devices (logically - it's deeply embedded system not server with "unlimited" space for large DB) - number is 8 I guess. So you cannot really deploy system where devices on both sides "randomly" meet and communicate securely (unless you do it on applicative layer which is what all the guys such Apple HomeKit or Google Weave).

RE: How to increase number of characteristics

Tim — Wed, 30 Sep 2015 11:03:04 GMT

Re update: Interesting, can you explain why the BLE security mechanism doesn't scale? Also is it necessary to do a full service discovery when connecting? If I already know all the GUIDs (because I designed the device) surely I don't need to?

RE: How to increase number of characteristics

endnode — Wed, 30 Sep 2015 10:34:46 GMT

My answer to this exceeds 900-word limit so I amend my answer above;)

(Btw. I hope you've tricked your mBed drivers/SDK to accept more UUIDs under one 128-bit base because all Characteristics should share the UUID base of their ancestor Primary Service, don't they?)

RE: How to increase number of characteristics

Tim — Wed, 30 Sep 2015 09:53:46 GMT

Jan's answer is great, but actually my problem turned out to be not due to the ATTR_TAB_SIZE. It was because I was using distinct UUIDs for all my characteristics. I totally forgot you are supposed to use a very small number of "base" UUIDs, and then just change the third and forth bytes.

custom_helper.cpp in mBed restricts the number of distinct base UUIDs to 8:

static const unsigned UUID_TABLE_MAX_ENTRIES = 8; /* This is the maximum number of 128-bit UUIDs with distinct bases that
                                                   * we expect to be in use; increase this limit if needed. */

I changed my UUIDs so that the bases match and now it is fine (I also had to increase the hard limit of 20 in nRF5xGattServer.h, but I didn't have to change the ATTR_TAB_SIZE from its default (0x600).

RE: How to increase number of characteristics

Tim — Wed, 30 Sep 2015 06:53:15 GMT

Perfect thanks! Yeah I could just use a single characteristic and write to/notify from it as if it were a pipe. But that's less discoverable and doesn't really seem like it's in the spirit of BLE!

RE: How to increase number of characteristics

endnode — Tue, 29 Sep 2015 21:34:31 GMT

Hi Tim,

BLE ATT (Attribute) layer which is base of GATT client/server layers in BLE Stack is configurable in latest Nordic SoftDevices. This is done during SoftDevice init by function sd_ble_enable(...). See API documentation in Nordic infocenter here and also read chapter 13.1 of S130 SoftDevice Specification (link to PDF version if you prefer). Note that changing Attribute Table Size has consequences on memory layout during linking of final firmware binary, see chapter 13.2.1 and other references in SDS.

Cannot leave the reply without this comment: what about redesigning your usage of Bluetooth LE ATT/GATT layer because most of the job could be done over single Service and Characteristic handles (actually 1 for the Service and 3 for the Char)? Or is it so that your device will really potentially offer so many characteristics to different applications? (e.g. if you have just one dedicated app then merge all features to applicative protocol running over one bi-directional characteristic which will safe resources as well as time during service discovery and I believe overhead will hardly harm your throughput unless you have very specific use case of many fast-changing but short and completely asynchronous values...)

Cheers Jan

Update on September 30, 2015:

Hi Tim,

This is exactly what I've tried to point out: while GATT client/server architecture looks like "in the spirit of BLE" it doesn't scale. I assume that if your 30 "properties" (whatever it is) are really independent and there should be "general" applications which can discover full (or partial) list and pick just few they should be rather grouped on Primary Service level, don't they? In every case you will have huge penalty (it can take even couple of seconds when you increase the GATT table usage) during each connection (if full service discovery will be done by central side) plus you will have troubles once you would like to secure the link (because BT Smart security mechanism doesn't scale in practice) so the whole concept of "general" properties in the practice collapses into "one bonded/paired central device with my application". And thus simple stupid "pipe" would do all the job more efficiently. In the system where server (peripheral) can accept only one connection at the time the principle of applicative fragmentation already on GATT layer somehow loses the charm. And when new devices supporting more complex server-client topologies arrive (compliant to BT SIG specs 4.2/5.0) - which will take couple of years - there will still be majority of the devices living in this old "low energy" (and resources) design. (And sweet secret: "one pipe for all things and applicative discovery mechanism on top of it" will work efficiently even on these "rich topologies";)

Just an opinion after my 2-year experience with BT Smart...

Cheers Jan