Reduce connection establish time

[sijohans]

Hello,

i have a BLE Peripheral that has a service that we use to simulate UART over BLE. Very similar to the nRF UART. I consider the time to establish a link that allows to send asynchronous data to be quite high. I'm using an android device to setup the link and i measure the time in this application. The peripheral supports a MTU size of 247 bytes, and this is negotiated during the setup.

This is the flow:

1. The device is found by the BLE scanner
2. Start time measurement
3. Connect to the device
4. When the onConnectionStateChange indicates a successfull connection, start a MTU negotiation.
5. When the MTU is negotiated, start a service discovery.
6. When the services are discovered, verify our service and that the corresponding characteristics exists with correct properties.
7. enable notifications by writing to the corresponding descriptor.
8. When the onDescriptorWrite event is fired from the gattCallback, the link is considered established.
9. Stop measuring time.

I've written a test application that simulates this repeatedly. When i run this test 1500 times i get the following results:

• Worst case: 3046ms
• Best case: 389ms
• Average: 867

I might run this test again to see if i can do more statistical measurements on the result. These are my parameters:

#define BLE_MIN_CONN_INTERVAL               MSEC_TO_UNITS(39, UNIT_1_25_MS)
#define BLE_MAX_CONN_INTERVAL               MSEC_TO_UNITS(80, UNIT_1_25_MS)
#define BLE_SLAVE_LATENCY                   0
#define BLE_CONN_SUP_TIMEOUT                MSEC_TO_UNITS(2000, UNIT_10_MS)
#define BLE_FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)
#define BLE_NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)
#define BLE_MAX_CONN_PARAMS_UPDATE_COUNT    3
#define BLE_APP_ADV_INTERVAL                320
#define BLE_APP_ADV_TIMEOUT_IN_SECONDS      0  

Any ideas of how to improve the connection time?

[endnode]

Oh yes, this is kind of known thing. The only mitigations seems to be:

• Use the shortest adv. interval possible (to increase chance that GAP Central will connect).
• Use as high scanning duty cycle as possible (on GAP Central side to increase chance that advertising packet will be detected).
• Avoid any LL/L2CAP/ATT otpional procedures like PDU or ATT_MTU extension, specification version exchange etc.
• Do as small GATT Server as possible (minimum of GATT Primary Service, GAP Primary Service and your own single Proprietary Primary Service with as few Chars/Descriptors as possible).
• Make GATT Server static (= avoid exposing Service Changed Characteristic) so GATT Client may cache it and skip GATT Service discovery procedure next time.
• Use GATT Service Discovery caching on GATT Client side if possible.
• Avoid Security Manager procedures such as pairing/bonding unless you really need them.

As you can see not many things are in your hands on high-level systems such as mobile and desktop platforms (iOS, Android, Windows, MacOS, Linux...) That's why this usually leads to designing simple GATT Profile with all security and fragmentation/flow/scalability management done on APP layer and also often sticking with default PDU and ATT_MTU sizes (because their gain on throughput is only visible for long connections and transfers - which seems not your problem if you care about connection times;). But maybe this is 2-3 years old approach and modern BT 4.2/5.0 devices will use new tricks how to overcome this problem (I'm curious to learn!). As you can see