AIR INTERFACE PACKETS （空中接口包）
在前面的學習中，我們知道了LL的狀態和角色是如何定義的，那么，在某一狀態下，和其它設備實體對應狀態之間的數據交換機制是什么呢？如何根據上層實體的指令，以及當前的實際情況，完成狀態之間的切換？在BLE協議中，這些工作由空中接口協議（Air Interface Protocol）負責。
鏈路層用於廣播信道(advertising channel)包和數據信道(data channel)包的報文只有一種格式：
從LSB即Preamble開始傳輸，最后傳輸MSB即CRC，數據包最短80 bits，最長2120 bits。
Preamble（前導碼）
所有鏈路層數據包都有一個8 bits的前導碼。對接收者來說，前導用於執行頻率同步、符號時序估計和自動增益控制(AGC)訓練。
廣播包的前導碼固定為10101010b（0xAA）；數據包根據Access Address的LSB為0還是1，有不同的前導碼。當Access Address的LSB為1，前導碼為：01010101b（0x55），否則前導碼為10101010b（0xAA）。
Access Address （訪問地址）
無線通信時，兩個設備處於同一個頻道進行通信，但是有時候可能有很多個設備在使用，那么多個設備處於同一個頻道的可能性就比較大，為了避免這種多個設備某時刻工作在同一頻率會造成的干擾，於是就有了Access Address。但是，即使是隨機數，可也有可能其他多個設備具有相同的訪問地址，所以，這里使用隨機地址讓AA(Access Address)不同是從概率基本等價於0來說的，即在隨機地址下，AA相同的概率可以忽略不計,關於AA的作用：
廣播包（Advertising packets）的Access Address是固定的：0x8E89BED6；數據包（Data packets）的Access Address是一個32 bits的隨機值，由處於Initiating State的設備生成，並按照Section 2.3.3.1（core_4.2）中定義的那樣發送連接請求，initiator應確保Access Address符合下列要求:
.不能有6個以上連續的0和1；
.不能是廣播的訪問地址；
.不能喝廣播的訪問地址只有1 bit 不同；
.不能4個字節都相同（1字節 = 8 bits的情況）；
.訪問地址應該超過24次轉換；
.它應在最高有效的6 bits中至少有兩次轉換。
Protocol Data Unit-PDU（協議數據單元）
廣播PDU和數據PDU
在介紹PDU之前，先了解RESERVED FOR FUTURE USE (RFU)的概念，在協議字段中任何標記為RFU的都保留供將來使用，RFU字段發送時需要設置為零，接收時忽略。
ADVERTISING CHANNEL PDU
廣播信道的PDU格式如下：
Herder的格式如下：
注：本文章系列是以core_4.2為藍本，在core_5.x中，數據格式有變更，前面說過，學習時先以低版本為例，學好了4.2規范,5.x規范便水到渠成。
TxAdd、RxAdd字段由具體的PDU Type決定其意義。Length字段表示廣播有效載荷字段的長度(以字節為單位)。長度字段的有效范圍為6到37字節。
PDU Type如下：
其中有4種PDU Type屬於advertising PDUs：
Advertising PDUs
• ADV_IND: connectable undirected advertising event；可連接的不定向廣播事件，最為常見的廣播類型，可接受掃描和連接請求；
該類型的負載數據為：
通過前面的介紹我們知道，PDU的范圍為2-257 octets，可以得到Payload的范圍為0-255 octets，這里顯然沒有達到最大字節數，所以剩余字節為RFU，發送時需要清零，接收時忽略；
AdvA，6 bytes的廣播者地址，由PDU Header的TxAdd bit決定廣播地址（AdvA）的類型（0： public，1： random）；AdvData，廣播數據，AdvData字段可能包含來自廣播者的廣播數據，示例：要求連接到任何中央設備的智能手表。
• ADV_DIRECT_IND: connectable directed advertising event；可連接的定向廣播事件，專門用於點對點連接，且已經知道雙方的藍牙地址，不可攜帶廣播數據，接受連接請求，拒絕掃描請求；
該類型的負載數據為：
AdvA，6 bytes的廣播者地址，由PDU Header的TxAdd bit決定廣播者地址（AdvA）的類型（0 ：public，1： random）；InitA，6 bytes的接收者（也是連接發起者）地址，由PDU Header的RxAdd bit決定設備地址（InitA）的類型（0： public，1 ：random）。注意，該數據包不包含任何Host(層)數據，示例：智能手表請求連接到特定的中央設備。
• ADV_NONCONN_IND: non-connectable undirected advertising event；不可連接的不定向廣播事件，拒絕連接和掃描請求；
該類型的負載數據同ADV_IND一致，那么這種PDU Type
有什么應用場景呢？示例：博物館中的信標，用於確定與特定展覽品的距離；
• ADV_SCAN_IND: scannable undirected advertising event；可掃描的不定向廣播事件，接受掃描請求，拒絕連接請求；
該類型的負載數據同ADV_IND一致，示例：倉庫貨盤信標，允許中央設備請求有關貨盤的其他信息。；
四種狀態是否允許回應廣播事件的PDU：
這些PDU由處於廣播狀態（Advertising State）的鏈路層發送，並由處於掃描狀態或發起狀態（Scanning State or Initiating State）的鏈路層接收。
有2種PDU Type屬於scanning PDUs 。
Scanning PDUs
• SCAN_REQ: sent by the Link Layer in the Scanning State, received by a Link Layer in the Advertising State；通過名字我們就可以知道，掃描請求，即掃描狀態的時候發送的消息，廣播狀態接收的消息；如果此時設備處於掃描狀態，當其接收到ADV_IND或者ADV_SCAN_IND類型的廣播數據的時候，可以通過該PDU，請求廣播者廣播更多的信息；
該類型的負載數據為：
ScanA，6 bytes的主機（掃描者）地址，由PDU Header的TxAdd bit決定掃描者地址（ScanA）的類型（0： public，1 ：random）；
AdvA，6 bytes的廣播者地址，由PDU Header的RxAdd bit決定廣播者地址（AdvA）的類型（0 ：public，1 ：random）。
AdvA，6 bytes的廣播者地址，由PDU Header的RxAdd bit決定廣播者地址（AdvA）的類型（0 ：public，1 ：random）。
注意，該數據包不包含任何Host（協議層的Host層，這里譯為主機會產生歧義）數據。
SCAN_RSP
• SCAN_RSP: sent by the Link Layer in the Advertising State, received by a Link Layer in the Scanning State，掃描應答，廣播態發送消息，掃描態接收。廣播者收到SCAN_REQ請求后，通過該PDU響應，把更多的數據傳送給接收者；
該類型的負載數據為：
AdvA，6 bytes的廣播者地址，由PDU Header的TxAdd bit決定廣播者地址（AdvA）的類型（0 ：public，1 ：random）；ScanRspData，掃描的應答數據，ScanRspData可能包含廣播者的主機數據。
有1種PDU Type屬於initiating PDUs：
Initiating PDUs
• CONNECT_REQ：This PDU is sent by the Link Layer in the Initiating State and received by the Link Layer in the Advertising State。連接請求，廣播態接收，發起態發送消息；當接收到ADV_IND或者ADV_DIRECT_IND類型的廣播數據的時候，可以通過該PDU，請求和對方建立連接；
該類型的負載數據為：
InitA，6 bytes的本機地址，由PDU Header的TxAdd bit決定發起者地址（InitA）的類型（0 public，1 random）；
AdvA，6 bytes的廣播者地址，由PDU Header的RxAdd bit決定廣播者地址（AdvA）的類型（0 public，1 random）；
AdvA，6 bytes的廣播者地址，由PDU Header的RxAdd bit決定廣播者地址（AdvA）的類型（0 public，1 random）；
AA ： Access Address ，可參考Vol 6，Part B （本文若無特殊說明，都是在這個大目錄下的章節）Section 2.1.2
CRCInit：它是一個由鏈路層產生的隨機值，defined in Section 3.1.1.
WinSize：defined in Section 4.5.3，transmitWindowSize =WinSize * 1.25 ms.
WinOffset：defined in Section 4.5.3 ， transmitWindowOffset =WinOffset * 1.25 ms
Interval ：defined in Section 4.5.1 ，connInterval = Interval * 1.25 ms.
Latency ： defined in Section 4.5.1 ，connSlaveLatency =Latency.
Timeout ：defined in Section 4.5.2， connSupervisionTimeout = Timeout * 10 ms.
ChM ：ChM字段包含指示已使用和未使用數據信道的信道映射。 每個通道均按照第1.4.1節（由於已經學習過，特標注出來方便查看，見下表1.2）中定義的數據通道索引位置定位。 LSB代表數據通道索引0，位置36的位代表數據通道索引36。值為0表示該通道未使用，值為1表示該通道已使用。 位置37、38和39中的位保留供將來使用。 注意：從RF信道映射到數據信道索引時，應注意在第二個廣播信道的位置處留有間隙（即廣播信道38的時候，數據信道為空，此處數據信道不連續，有間隔）。
Latency ： defined in Section 4.5.1 ，connSlaveLatency =Latency.
Timeout ：defined in Section 4.5.2， connSupervisionTimeout = Timeout * 10 ms.
ChM ：ChM字段包含指示已使用和未使用數據信道的信道映射。 每個通道均按照第1.4.1節（由於已經學習過，特標注出來方便查看，見下表1.2）中定義的數據通道索引位置定位。 LSB代表數據通道索引0，位置36的位代表數據通道索引36。值為0表示該通道未使用，值為1表示該通道已使用。 位置37、38和39中的位保留供將來使用。 注意：從RF信道映射到數據信道索引時，應注意在第二個廣播信道的位置處留有間隙（即廣播信道38的時候，數據信道為空，此處數據信道不連續，有間隔）。
Hop ：Hop字段指示4.5.8.2節定義的數據通道選擇算法中使用的hopIncrement。它是一個在5到16之間的隨機值。
SCA ： SCA字段指示用於確定最壞情況下主機的睡眠時鍾精度(如第4.2.2節所定義)的masterSCA。SCA字段的值應設置為表2.2中定義的值：
DATA CHANNEL PDU
前面介紹的都是廣播通道的PDU，下面將開始學習數據通道的PDU相關知識。
數據通道PDU有一個16位報頭（Header），一個可變大小的有效載荷（Payload），並可能包括一個消息完整性檢查(MIC)字段。
MIC字段不應包含在未加密的鏈路層連接中，也不應該包含在使用零長度有效載荷的數據通道PDU的加密鏈路層連接中，MIC字段按照[Vol. 6] Part E, Section 1定義的方式計算。
Payload格式取決於Header的LLID字段。如果LLID區域是01b或10b，數據通道PDU有效載荷字段包含第2.4.1節定義的LL Data PDU。如果LLID字段是11b，那么數據通道PDU有效載荷字段包含一個LL Control PDU，見2.4.2節的定義。LLID字段為00b表示保留。
The NESN bit of the Header is defined in Section 4.5.9.
The SN bit of the Header is defined in Section 4.5.9.
The MD bit of the Header is defined in Section 4.5.6.
Header的length字段指示凈荷（Payload）和MIC（如果包含）的長度。 長度字段的范圍是0到255字節。 有效載荷字段的長度應小於或等於251字節。 MIC的長度為4個字節。
The SN bit of the Header is defined in Section 4.5.9.
The MD bit of the Header is defined in Section 4.5.6.
LL Data PDU
LLID=01b時，這種類型的PDU，要么是一個未傳輸完成L2CAP message（長度超過255，被拆包，此時不是第一個），要么是一個空包（Header中的Length為0）。主機的鏈路層可以向從機發送一個空PDU，以使從機能夠響應任何數據通道PDU（包括一個空的PDU）。
LLID=10b時，這種類型的PDU，要么是L2CAP message的第一個包，要么是不需要拆包的完整的L2CAP message，值得注意的是，這種場景下的Header中的Length不能為0。
LL Control PDU
LLID=10b時，表示這個數據包為LL Control PDU，用於控制鏈路層的連接。
Opcode字段標識LL Control PDU的不同類型，如表2.4中所定義的那樣。CtrData字段由Opcode字段決定，除非另有明確說明，否則CtrData字段中包含整數的所有字段都應解釋為無符號的。
如果收到未使用或不支持的LL Control PDU，則鏈路層應以LL_UNKNOWN_RSP PDU進行響應。 LL_UNKNOWN_RSP PDU的UnknownType字段應設置為未使用或不支持的操作碼的值。
如果收到的LL Control PDU的操作碼無效，即操作碼字段設置為保留供將來使用（Reserved for Future Use）的值或無效的CtrData字段，則鏈路層應以LL_UNKNOWN_RSP PDU進行響應。 LL_UNKNOWN_RSP PDU的UnknownType字段應設置為無效操作碼的值。
至於每個 Control PDU的詳細介紹，可以看Vol 6 ，Part B，2.4.2.這里暫時不介紹和前面的原因一樣，有一些依托於后續章節的知識。
BIT STREAM PROCESSING （比特流處理）
藍牙設備應使用以下小節中定義的比特流處理方案。
在接收包時，首先要檢查訪問地址（AA），如果訪問地址不正確，將被拒收，反之則被視為已收到。如果CRC不正確，數據包將被拒絕，這樣的數據包是無效的，反之則數據包將被認為是有效的。一個數據包只有在被認為是有效的情況下才能被處理。CRC錯誤的數據包可能導致繼續連接事件，如第4.5.1節中所述。
CRC必須在所有鏈路層數據包的PDU字段上計算（即CRC是計算PDU的，不包括前導（Preamble）和訪問地址（AA）字段）。 如果PDU被加密，則在對PDU進行加密之后應計算CRC。
24 bits的CRC校驗值在發送的時候和其他字段不同，不知道你是否還記得，我們在前面的文章中說了CRC和MIC的傳輸不是LSB先行，這里，我們終於到CRC了，CRC在發送時，先發送MSB即最高有效位，再發送LSB即最低有效位。
DATA WHITENING（數據白化）
數據白化用於避免長序列的零或一，例如數據比特流中的0000000b或1111111b。 白化（whitening）應該應用於所有鏈路層的PDU和CRC字段，並在發送器中的CRC字段之后執行。 除白（De-whitening）是在接收器中的CRC字段之前執行的（請參見圖3.1）。至於具體的白化算法，就不在此討論了，感興趣的可以自行查閱。
NOTE：以后的內容將在微信公眾號更新。