关于匹配和绑定中导致断开在广播延时的问题

请教一下：

uint32 passkey = 0; // passkey "000000"// passkey "000000"，密钥
uint8 pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;//配对模式，配置成等待主机的配对请求
// uint8 pairMode =GAPBOND_PAIRING_MODE_INITIATE;
uint8 mitm = TRUE;
uint8 ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
uint8 bonding = TRUE;
GAPBondMgr_SetParameter( GAPBOND_DEFAULT_PASSCODE, sizeof ( uint32 ), &passkey );
GAPBondMgr_SetParameter( GAPBOND_PAIRING_MODE, sizeof ( uint8 ), &pairMode );
GAPBondMgr_SetParameter( GAPBOND_MITM_PROTECTION, sizeof ( uint8 ), &mitm );
GAPBondMgr_SetParameter( GAPBOND_IO_CAPABILITIES, sizeof ( uint8 ), &ioCap );
GAPBondMgr_SetParameter( GAPBOND_BONDING_ENABLED, sizeof ( uint8 ), &bonding );
}

从机发起的绑定和匹配，要把pairmode的参数改为红色字体部分，但是我发现，改为这样，当蓝牙从连接到断开的过程中，static void peripheralStateNotificationCB( gaprole_States_t newState )函数不能马上反应断开的状态，而是要延时一段时间才反应过来。而吧pairmode改为黑色字体部分时，同样的过程，static void peripheralStateNotificationCB( gaprole_States_t newState )能马上反应断开的状态，请问这是什么原因造成的？如果我要匹配和绑定，怎样才能解决上述的延时问题？急！急！ 

waiting,

你是连上立马断开？

改成你的红字的话，从设备会主动发起配对请求。

黑字的话，如果是iOS设备，或者一些其他设备，都不会来和你配对的，你连接过程自然会快一些。

是这样子了，如果是黑字部分，断开后马上可以回到广播状态，但是红字部分，断开后要过一段时间才会进入广播状态，这个我是通过回调函数打印出来观察的。就是不明白这是什么回事？