Disconnection request from iOS device not forcing disconnection from nRF52

[Mike Austin (LPI)]

This is my environment:

IDE: VSC

SDK: NCS v2.2.0

iPhone 14 running iOS 16.6

nRF52-DK

This is how I have things set up:

My nRF52-DK is a sensor that is recording various events.  I have either a custom App on the iOS device, or I am using the nRF Connect App - behaviour is the same with both.

• nRF52-DK starts advertising, so is acting as the Peripheral.
• iOS device attempts a connection, so is acting as the Central.
• once connection is made, it can read any of the sensor data.  All of the services/characteristics have L2 security, which forces bonding/pairing to occur.  The data then gets successfully read.
• Once bonding/pairing has been established, the CTS functionality is enabled, which means the nRF52-DK then becomes the Client and the iOS device becomes the Server.  CTS info is successfully transferred.  All good so far
• However, at this point, a disconnect request is initiated by the iOS device.  I can see this in the logs when using the nRF Connect App, and our App Developer can see the same thing when using his App.  However, we do not see a successful disconnection initiated on the nRF52-DK, which means it remains connected.  This presents a bunch of issues.
• Up until this point in time, we've been implementing a "brute force" solution, whereby whenever the iOS device reads one of the Services/Characteristics, it also writes to a "Disconnect Service" on the nRF52-DK, which then forces a disconnection.  That works, but it doesn't seem like the correct approach to me.  A disconnection request from either Client or Server should result in a disconnect of both devices, but this isn't happening.
• If I disable the CTS functionality, I can get the iOS disconnection request to work successfully.  However, the nRF52-DK will only show a successful disconnection ~ 30secs after the connection was first made.  So, if I connect, then issue a disconnect request, I have to wait 30sec for this to occur.  If I connect, then wait 15sec before issuing the disconnection, the disconnection will occur 15sec later.  And if I connect, then issue the disconnection request anytime from 30sec or more after, the disconnection occurs immediately.

So, there are two issues here:

1. CTS seems to prevent a disconnection from the iOS device actually resulting in a disconnection of the connections

2. Without CTS, there is a minimum 30sec connection time before a disconnection will occur

Is anyone able to help me resolve both these issues?

Best regards,

Mike

[Karl Ylvisaker]

Hello Mike,

Thank you for the update and for confirming that this is not an issue when testing against non-iOS devices centrals.
Perhaps there exists some sort of 'minimum connection time' within iOS? I would be surprised to learn this, but again I do unfortunately not have any personal experience with developing iOS applications.

In this case I would have to recommend that you reach out to Apple through the iOS app developer forums to see if they can confirm that this is the correct behavior. Perhaps they can also explain if there is any way to work around this potential 'minimum connection time'.

Best regards,
Karl

[Mike Austin (LPI)]

Hi Karl,

Set up the sniffer.  Watching the traffic being sent/received by my DK, I can see that it is in fact taking some time for iOS to issue the disconnect request.  So, for some reason, iOS requires a minimum ~ 30sec connection time before it will allow the connection to be removed.  Android doesn't have this limitation.

Our workaround is to have a "Disconnect Service" on the Peripheral.  To terminate the connection, the Client writes to the characteristic for this Service.  The Peripheral then initiates the disconnection in response to this.  This all happens instantaneously, regardless of the length of the connection period.

Still not clear why iOS behaves like this, but its not something I can change anyway, so our workaround is what we have settled on as a solution

Cheers,

Mike

[Karl Ylvisaker]

Hello Mike,

Mike Austin (LPI) said:

Set up the sniffer. 

Great, I am glad to read that you've got the sniffer up and running - it is a very powerful tool to have when developing BLE application.

Thank you for the update about the iOS findings - your workaround sounds like a good approach for now, but I would still recommend that you reach out to Apple or an iOS forum to check if it is possible to disable or work around this behavior, or if there is anything else/underlying reason for this behavior, just in case. In either case I am glad that you've got a solution in place that works for your application.

Please do not hesitate to open another ticket if you should encounter any other issues or questions in the future.

Good luck with your development!

Best regards,
Karl