Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

[endnode]

Dear Nordic team and community,

Have you encountered the problem where standard BT4.0/4.1 GAP Peripheral device would be "blocked" from connection (kind of "denial of service" situation) by too many actively scanning GAP Scanners/Centrals? We are seeing this with certain mobile phones (especially Android) in "observing" role and this is pretty independent on adv. interval we use (typically 20-200ms). All adv. events are "loaded" with SCAN_REQ packets when there are 5 or more "scanning" phones and beside SCAN_REQ collisions (which are typically not critical for BLE solutions) basically all CONNECT_REQ collide with some SCAN_REQ packet and thus Peripheral never follows the connection.

Any suggestions (beside trying to lower scanning activity on phones' side which obviously isn't always possible)?

Thanks Jan

[Hung Bui]

Hi Jan,

I agree on what you are discussing in the comments. It could be an issue if we have an environment where several phones, device keeps scanning and sending scan request or connection request.

I just want to add, some solutions if you want to establish a connection in a crowded environment:

• Reduce TXpower when advertising, and put the device you want to connect closer to your central. This is to avoid the unwanted scanners to send scan/connect request.

• Use Out of Band to send address of the central to your peripheral for example with NFC. After that let the peripheral advertising in directed mode so that other scanner will not send scan/connect request

[endnode]

Thanks, this is helpful (although not applicable when GAP Peripheral is also mobile phone where you cannot affect such low-level BLE parameters;). So have you heard about such complains from the users of your chips or during your in-house tests/demos?

[Aleksander Nowakowski]

Hi, on Android you may set the TX power for advertisements. There are 4 options to choose from: -21 bBm, -15 dBm, -7 dBm and +1 dBm. You may also set the connectible/non-connectible flag. On iOS there also should be something like that (see CBAdvertisementDataTxPowerLevelKey).

[endnode]

Thanks Alex, this is interesting, I'm obviously not mobile developer so I missed that! It's worth trying, will recommend to our mobile development team...

[Aleksander Nowakowski]

Hi, some insights from an Android developer. Background scanning on Android of course can be done using high power scanning, but it's a very bad practice and leads to draining the battery quickly. There are 4 options to scan: high power (continuous), balanced (2 sec out of 5), low power (0.5 sec/5 sec) and opportunistic (app gets updates only when another app is scanning). All Android tools, like Physical Web or Google Play service, that may scan in the background, do it in least disturbing mode, so more phones are required to fully block connections, unless all they open their favorite app (nRF Connect, of course ;) ) and start scanning at the same time. Also, it used to be, that some phones (Nexus 4 or 7) were sending only one Scan Request per scanning to one device. This approach was preventing from DoS, but also from tracking changing RSSI, so it has been fixed.