How do I minimize the number of connection messages sent?

Question

I'm looking at a BLE application using the nRF51822 where we need to send data maybe once every 10 minutes, so it seems like disconnecting in between sending messages will save a lot of battery life. However, each time a connection is made, in between advertising and the actual data transfer, there are a whole bunch of L2CAP messages being sent at about 25 ms intervals. 
 I haven't yet worked out exactly what they're for, but it seems like they're to do with negotiating the connection parameters and/or synchronizing between the devices. Many of them have the data type L2CAP-C, with no actual data being sent, and some of them contain link layer commands. 
 I assume they are unavoidable, but what can I do to minimize the number of messages being sent? Failing that, what exactly are they, and what are they for? 
 Thanks in advance!

Carles · Accepted Answer

I'm not quite sure what you mean by traces, but this is what I get using a packet sniffer: 
 
 Yes, I meant the output of a sniffer. 
 
 LL_Version_Ind
ATT_Read_By_Type_Req
LL_Version_Ind
LL_Incryption_Req
ATT_Read_By_Type_Rsp
LL_Encryption_Rsp
LL_Reject_Ind
ATT_Read_By_Type_Req
ATT_Error_Response
ATT_Write_Req
ATT_Write_Rsp
ATT_Read_Req
ATT_Read_Rsp
ATT_Read_Req
ATT_Read_Rsp
ATT_Read_Rsp
ATT_Write_Req
ATT_Write_Rsp
ATT_Read_Req
ATT_Read_Rsp
ATT_Write_Req
ATT_Write_Rsp 
 
 Service Discover, not necessary to do this every time? 
 
 ATT_Handle_Value_Ind
ATT_Handle_Value_Confirm 
 
 The actual data exchange. You could disconnect after this. 
 
 ...Lots of blank messages... (~300) 
 SIG_Connection_Param_Update_Req
LL_Connect_Update_Req
SIG_Connection_Param_Update_Rsp 
 ...some more blank messages... (only 10 or so) 
 
 A connection Parameter Update, you don't need this if you've already sent the data you wanted with the Handle Value Indication. 
 
 LL_Terminate_Ind 
 
 The disconnection. 
 
 So it looks like that's the service discovery being done, then a wait for the connection parameter update to happen, then I assume LL_Terminate_Ind means something like "Stop service discovery and wait for indications". 
 
 No, it means "disconnect now". 
 
 I don't know how much of this is set by the peripheral end of the connection - for example, maybe the blank messages could be eliminated if the control app responded faster? At the moment I'm using a modified version of the Temperature sensor example code, and the Nordic iOS app, but we are working on our own BLE app for Android, so we will be able to control both ends of the connection. 
 
 The service discovery is being performed (I assume) by the central, since you are most probably acting as an ATT server. You will need to optimize the phone side no to do that every time (bonding and then relying on Service Changed). 
 
 Would enabling bonding be the best way to eliminate the service discovery, or are there other ways to do that? And is the delay most likely to be coming from the Central, or the Peripheral? 
 
 Yes, bonding should eliminate the whole discovery procedure.
The delay is caused by you not disconnecting immediately after the Handle Value Confirm, which I believe you should do if all you want is to send a value from peripheral to central.
Either the peripheral or central could trigger that disconnection.