How to increase number of characteristics

[Tim]

Hi,

Using S130 via mBed, I'd like to have a fairly large number of characteristics (say 30). Unfortunately this seems to be too many, as sd_ble_gatts_characteristic_add() returns an error after I get to maybe 18 characteristics (i.e. 17 works, 18 doesn't, it also depends on the specific characteristics). Also the mBed code has a hard limit of 20 characteristics (well actually the code is buggy and will overflow/crash if you go past 20). I have submitted a patch for that.

As I understand it, some data about the characteristics (I assume UUID, characteristic value buffer, CCCD, etc.) is stored in an internal table of the softdevice. Is there any way to increase the size of this table?

According to the documentation you can specify BLE_GATTS_VLOC_USER instead of BLE_GATTS_VLOC_STACK in custom_helper.cpp, but I don't really want to change the library code, and also it says it will only store the attribute value in user memory, which is only one or two bytes in my case. The UUID is much bigger, so I doubt I'll save much there.

Is there any solution?

[endnode]

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

[Tim]

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!

[Tim]

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?

[endnode]

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

[endnode]

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

[endnode]

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