BLE的配對是一個比較繁瑣的過程，需要熟悉規範，隻有明白其中的原理才能更好的了解這個過程。
首先需要明确一點：配對的目的是為了加密通訊鍊路，保證資料安全，綁定是為了簡化配對流程。
配對綁定過程說明：
1 配對資訊的交換
2 生成STK(短期秘鑰)加密鍊路
3 鍊路加密後就可以安全分發各種秘鑰了，如果需要綁定，那麼也會生成LTK(長期秘鑰），雙方都會存儲LTK。
4 LTK配置設定之後，每次重新連接配接時雙方用LTK與會話秘鑰分散器等其他資訊最終生成一個會話秘鑰，真正的加密是用這個會話秘鑰，其實這點也與大多數加密機制類似。
下面簡單分析一下nrf協定棧中關于配對部分的流程。
在NRF52832（SDK 11.0 softdevice s132）中與鍊路安全相關的事件：
BLE_GAP_EVT_SEC_PARAMS_REQUEST
BLE_GAP_EVT_SEC_INFO_REQUEST
BLE_GAP_EVT_CONN_SEC_UPDATE
BLE_GAP_EVT_AUTH_STATUS
（1）在配對資訊交換階段，BLE_GAP_EVT_SEC_PARAMS_REQUEST事件會由協定棧上報給應用層:
（2）在這個事件中，從機會把自己的資訊與主機進行交換，其中就包含了從機的IO能力、配對完成是否綁定等（在sd_ble_gap_sec_params_reply第三個參數定義）資訊。
1） 如果指定了從機具有顯示能力，即BLE_GAP_IO_CAPS_DISPLAY_ONLY，那麼調用sd_ble_gap_sec_params_reply後，應用層會收到BLE_GAP_EVT_PASSKEY_DISPLAY事件，從機将協定棧生成的随機密碼顯示到螢幕即可，此時主機也會出現一個配對框，使用者輸入從機顯示的密碼即可完成配對。若從機沒有輸出能力，那麼可以指定為BLE_GAP_IO_CAPS_NONE,此時主機不再要求輸入密碼，而是詢問是否同意配對。若密碼比對或使用者同意配對，那麼配對過程繼續，直到協定棧上報BLE_GAP_EVT_CONN_SEC_UPDATE事件代表配對成功：
2.如果指定配對完成後綁定，那麼協定棧會進行LTK的分發，秘鑰分發完成後，協定棧會上報<code>BLE_GAP_EVT_AUTH_STATUS</code>事件表示：
（3）LTK分發完成後，從機可以将協定棧傳回相關秘鑰資訊儲存下來：
至此整個配對綁定過程完成。
下面再分析一下，當鍊路重建立立時的情況。
上面提到，綁定操作是為了簡化配對流程。當雙方都儲存有配對資訊時（最重要的是LTK），可以直接使用LTK參與會話秘鑰的生成，一般情況下，主機會發起加密請求，從機會響應加密請求，在nrf協定棧中，相關事件是BLE_GAP_EVT_SEC_INFO_REQUEST:
收到BLE_GAP_EVT_SEC_INFO_REQUEST事件後，從機會查詢本地有沒有目前連接配接的主機相關秘鑰資訊，并把查詢結果傳遞到協定棧給主機回應。那麼到底是以什麼作為比對标準來查詢這個秘鑰資訊呢，首先想到的是主機的MAC，沒錯，确實是MAC位址，但是除了MAC位址，還有一項diversifier（分散器）,記為EDIV：
如果單單是MAC位址，就無法解釋iOS系統Private Non-Resolvable address的現象：iOS每次重新開機系統或重新開機藍牙，BLE的MAC位址都會被改變，話說是為了防止裝置被追蹤。
diversifier的值由發起配對的一方傳送，接收的一端進行比對，除了diversifier之外，還有随機數Rand、初始向量IV等與加密相關的參數随着加密請求LL_Encryption Req發送給對方。
一旦比對成功，後續通訊鍊路就可以進入加密狀态，下面是通過空中抓包關于主機發起加密的過程：
可以看到，在M->S的加密請求包中，包含了4個域，都是與加密相關的字段，其中一項就是EDIV，随後S->M的加密響應中，從機向主機傳送了自己的STK和IV，主從雙方準備好之後，從機發起開始加密請求，在随後的資料包中，協定分析軟體顯示多了一項Security_Enabled，可知鍊路已進入了加密狀态。
如若一切順利，上述過程沒有什麼問題，一旦一個環節出錯，配對就無法完成了。例如當從機儲存的配對資訊失效了（一般會儲存在Flash中，Flash并不是百分之百可靠），就無法再正确的進行鍊路加密。
在我的這個案例中，從機是nrf52832，主機是iOS系統，業務流程簡單：
從機通過使用者app配對完成後，可以脫離app而獨立工作，并接收ANCS消息。
在測試過程中發現，主機在斷線後（時間和次數不确定），不再主動連接配接從機，手動連接配接從機後，ANCS通知也不正常，并且再次斷線後也不會回連。
經過無數次的問度娘，也沒有找到相關的問題，最後無奈，隻能使出殺手锏：通過抓包分析
可以看到，主機在連接配接上從機後與從機交換了協定版本資訊，接着就發送了一條加密請求，要求從機進行鍊路加密，後面的資料包中，我們看到從機第二次回應時，發送了一個LL_Reject_Rsp，一開始不知道這個包的含義，但是Reject明顯不是什麼好事，對比正常的響應包，此處應該是Start_Encryption Req才對，經過多次實驗得知，iOS系統在5次重連發加密請求都收到LL_Reject_Rsp時，就不會再回連該從機（目前還沒找到apple相關資源）， 那麼，我的思路就是在從機查找不到主機的配對資訊時，向主機發起配對請求，要求使用者重新确認并配對。
核心操作就在dm子產品：<code>dm_security_setup_req()</code>，向主機發起配對請求。
這個方案基本上可以解決這個問題，但如果使用者沒有來得及産看手機并确認配對，且重連次數連續超過5次，系統還是會停止回連從機。