Do iOS BLE Connection Parameters also apply to iOS Slave/Peripheral?

Question

Apple provides requirements on BLE connection parameters: https://developer.apple.com/library/archive/qa/qa1931/_index.html

Do these assume the iOS device is in master (central) mode, or do they also apply to slave (peripheral) mode?

Given that the master ultimately defines the connection parameters (i.e. it can reject parameter adjustment requests from slave), if a non-iOS master specifies "non-compatible" connection parameters, does the iOS device just skip/ignore master packets/frames that are non-compliant? I don't see how this could be the case if the iOS BLE stack is Bluetooth certified. I.e., it would seem that iOS cannot enforce any restrictions on BLE communication if the iOS device is connected in slave mode.

---

Edit: One example of where an iOS peripheral/slave would presumably break spec is in vol 6, part B, section 4.5.1 of BT spec 5.0: "When connSlaveLatency is set to zero the slave device shall listen at every anchor point. If the slave does not receive a packet from the master after applying slave latency, it should listen at each anchor point and not apply slave latency until it receives a packet from the master."

Therefore, regardless of whether slave latency is zero or non-zero, the slave must be able to accommodate listening at every anchor point. So unless the iOS peripheral is refusing to enter a connection with a BLE central of non-compatible connection parameters (or will end the connection if the BLE master changes connection parameters mid-connection), then the iOS slave must comply or does not satisfy the spec. So would it be considered "in-spec" if the iOS BLE peripheral/slave stack will not enter or end a connection regardless of the user application's wishes?

Answer 1

We have used a product (BLE device) in production for a long time, that communicates with an iOS device that acts as a slave. Our product is the master device. We use connection parameters that are outside Apple's guidelines and have not seen any problem so far. Per Bluetooth specification a slave cannot reject the connection parameters specified by the master, so the fact that it works is expected.

The only thing Apple could do is disconnect the link (either immediately after connection setup or after a connection parameter update), but it seems they haven't gone that far. I don't think they'll ever do that since that would probably be problematic and a lot of support calls to Apple...

Notice that the Bluetooth specification suggests to disconnect if the parameters are unacceptable (but Apple doesn't seem to do that):

If the requested or updated connection parameters are unacceptable to the Central or Peripheral then it may disconnect the connection with the error code 0x3B (Unacceptable Connection Parameters). Devices should be tolerant of connection parameters given to them by the remote device.

Answer 2

Apple set further regulations on the BLE specification, and it is withing BLE specification. If the iOS device becomes a Central (Master) device, the Central side has the right to accept the connection interval change. It seems that iOS devices are implemented to reject connection interval requests if they do not follow Apple's rules. I think they would like to protect their products, like power consumption. I don't know about the case when the iOS device is a peripheral role. But the root of the concern/concept is the same, so I think the iOS peripheral device is going to disconnect your central one when your central device does not follow Apple's rule. Have you ever tried it before? How was that? Disconnected??