1、BLE整個協議棧架構：
2、首先看一下 LL層數據包的結構
PDU即爲協議數據單元，長度爲2~39Bytes。
Ble 分爲廣播態和連接態，所以PDU幀格式就會有兩種：
廣播態下PDU格式如下：
前2Bytes爲頭，既然是廣播態，廣播包中就會包含藍牙地址信息，所以Payload中的前6Bytes爲藍牙地址信息。
連接態下PDU格式如下：
前2Bytes爲頭，Payload中沒有藍牙地址信息，MIC 4個Bytes，只有在加密鏈路中才會存在。
LL層的Payload數據爲其上層L2CAP層協議的幀結構。
3. L2CAP協議層的數據幀結構如下：
L2CAP層幀結構：2Bytes的Len + 2Bytes的Ch ID + Information payload，同樣的道理 L2CAP 協議層Information payload
也是其上層ATT協議層的數據幀結構。
4、ATT協議層的數據幀結構如下：
如上，ATT協議幀結構包含1Bytes的Opcode+2Bytes的handle+（ATT_MTU-3）Bytes的真正有效數據。
Opcode用來指示write、notify或者indication的。即主機通過write將數據傳給從機，從機通過notify或者indication的方式將數據傳給主機。
handle爲具體哪個特徵值的句柄。
value爲真正有效的數據。
nordic的4.0協議棧中默認ATT_MTU只支持默認值即23。所以上層應用可發送的最大數據就是20Bytes了。
問題：這個23是怎麼來的呢？爲什麼LL層PDU最多支持39Bytes，到上層這裏就是20Bytes了呢？
計算方法：LL層PDU的39B - LL層PDU header 的2B - LL層Payload中廣播態中6B的ble address - LL層Payload中連接態中加密下的 4B的MIC - L2CAP層2B的Length - L2CAP層2B的Channel ID - ATT層1B的Opcode - ATT層2B的Handle = 20B
注意：這裏的計算一切都是最簡單的計算方法，比如同時減掉了LL層Payload中廣播態中6B的ble address 和 LL層Payload中連接態中加密下的 4B的MIC。
本文參考了 nRF52832 — 提高藍牙BLE的數據傳輸速率 這篇文章。非常感謝這位大神。
注：
GATT_Indication：從機通知主機後，主機需要調用simpleprofile_writeattrcb，讀取從機的數據。
GATT_Notification：從機直接發送給主機。
GATT_Indication和GATT_Notification的區別就在於主機是否回確認信息。