nRF8001 and ChangeTimingRequest: 30 second delay

Question

I'm working on a project that involves an nRF8001-based device as a Bluetooth Smart slave, in combination with master-side software running on an iPhone. 
 When the devices initially connect, the master downloads a series of log entries from the slave. There can be several hundred of these, each of which requires a round trip to transfer, so the slave tries to set the connection timings to a low value by sending an ACI ChangeTimingRequest packet to the nRF8001. (That is, it specifies that the connection interval and latency be low, so that connection events are frequent.) 
 Once the log has been transferred, power consumption on the slave becomes a more important concern than raw throughput, so the slave resets the timings to make connections less frequent. 
 One thing I've noticed about this system is that there's often a 30-second delay between the ChangeTimingRequest and the master actually setting the new timings. 
 I had assumed that the fault lay with iOS on the master side, but I now have a BTLE sniffer, and the packet traces appear very incriminating for the nRF8001. From firmware debugging, I see the ChangeTimingRequest go out over the ACI link with no delay. Then the nRF8001 sits on the request for 30 seconds. Finally, the SIG_Connection_Param_Update_Req packet goes out over the air, and the iPhone responds immediately with an LL_Connect_Update_Req. 
 The effect appears to be some sort of throttle, since the first timing update in a connection often goes through immediately. Later updates usually get delayed by 30 seconds. 
 There's no mention of this behavior in the documentation, and it's really quite counterproductive. It seems to me that the slave should be able to request timing changes as often as it pleases. 
 So, I guess my questions are: 1) Is this intentional or is it a bug?, and 2) Is there a workaround? 
 Thanks!

David Edwin · Accepted Answer

The ChangeTimingRequest is tied to the L2CAP Connection Parameter Update request in the specification, that specifies that the timing change should not be requested more often than 30 seconds. In addition there are issues in iOS and Android (Samsung) when the Connection Parameter Update request is requested faster than 30 seconds. This is likely due to implementation issues on the respective operating systems. 
 "The Peripheral shall not
send an L2CAP Connection Parameter Update Request command within
TGAP(conn_param_timeout = 30 seconds) of an L2CAP Connection Parameter Update
Response being received. When the Central accepts the Peripheral initiated
Connection Parameter Update, the Central should initiate the Link Layer
Connection Update procedure defined in [Vol. 6], Part B Section 5.1.1 with the
required connection parameters within TGAP(conn_param_timeout = 30 seconds ). " 
 However in some cases when your required timing params are placed in the GAP Characteristic called Preferred Peripheral Connection Parameters, the peer device (Windows and maybe Android) will automatically connect at that connection parameter, this may help in mitigating the issue a bit.