本文涉及如下BLE問題：
-
BLE設備是如何被發現的
-
如何快速的找到BLE設備或者如何降低廣播階段的功耗
-
BLE廣播通道/頻道(channle)上的PDU
1. 廣播的目的
- 讓別人能發現自己，對於一個不廣播的設備，周圍設備感覺不到其存在的，因此，要讓別的設備能發現，則必須向外廣播，在廣播中可以帶上豐富的數據，比如設備的能力，設備名字以及其他自定義的數據，這也就有了第二種可能。
- 給不需要建立連接的應用廣播數據，比如一個BLE溫度計，其本身可以不接收任何連接，而可以選擇通過廣播將溫度發送出去。檢測者只要監聽廣播就能獲取當前的溫度。
掃描者只有在收到廣播數據后，才能去與廣播者建立連接。廣播是周期性的將廣播數據從廣播通道上發送出去，這里有如下幾個問題：
1. 廣播通道，廣播數據是在37/38/39通道上將廣播出去，當然也可以只配置在某一個廣播通道上發送
2. 廣播數據：即廣播類型的PDU，廣播所攜帶的信息。
3. 周期性：即廣播間隔(advertising interval)
一個廣播包在37,38,39分別廣播出去為一個廣播事件(Advertising event),
以一定的時間間隔廣播數據，這個間隔稱為稱為advertising interval，為了改善設備的兼容性,在兩個廣播時間間隔之間，還有加上一個隨機的0-10ms的delay時間。
時間關系如下：
Advertising event的周期= advertising interval + delay
其中：delay是一個0-10ms的隨機數。
advertising interval的范圍：20ms – 10.24s，並且要求是0.625ms的整數倍。
2. 掃描
掃描是為了獲取設備信息，發現周圍設備，分兩種情況：
被動掃描(Passive scan)：這種情況，掃描者不發送任何信息，只監聽廣播數據，掃描者能收到廣播，廣播者並不知道掃描設備的存在：
主動掃描：掃描者在接到廣播數據(ADV_IND)后，主動發起掃描請求(SCAN_REQ)，廣播者接到掃描請求回應掃描(SCAN_RSP)，掃描回應(SCAN_RSP)也可以攜帶廣播者數據：
但需要注意的是，掃描者發送SCAN_REQ請求無法攜帶有效用戶數據(參考掃描類型的PDU Payload)，因此廣播和掃描者之間是單向通信，掃描者能知道廣播者信息，但廣播者無法知道掃描者信息。
廣播者只是在廣播通道發送廣播數據，並不知道任何scanner的存在，advertiser和 scanner之間也不存在任何同步方式，只有廣播和掃描所在的通道隨機重合時，廣播包才能被掃描設備收到，因此，和廣播設備一樣，掃描設備也有一些時間參數要求。
掃描有兩個重要的參數：scan interval 和scan window
Scan interval：定義多久發送一次掃描請求，
Scan window：定義掃描持續的時間是多長
Scan interval 的取值范圍是：2.5ms-10.24s
advertiser 和 scanner之間不存在任何同步方式，只有廣播和掃描所在的通道隨機重合時，雙方才能發現。
對於廣播和掃描而言，功耗主要消耗在發送或者接收數據期間，因此，廣播間隔和掃描間隔對功耗有很大影響，不同的應用應根據實際設置合適的間隔。
3 初始化連接(Initiating)
當接到廣播數據后，scanner可以發起建立連接請求，建立連接請求的數據包(CONNECT_REQ)是在廣播通道上發起的。如下所示：
CONNECT_REQ請求中會帶上重要的連接參數，包括連接時間間隔，supervision timeout，以及和跳頻相關的參數，並且在建立連接后，切換到數據通道上交互數據。這些將在連接的建立中詳細敘述。
4. 廣播channle上的PDU的展開
將廣播通道的PDU結構進一步展開如下：
1. PDU Type：指示PDU的類型，PDUType有七種，分別如下：
7個類型的PDU，分為三類：
-
四個廣播類型的廣播PDU
-
兩個掃描類型的PDU
-
一個發起連接PDU
2 RFU: reserved
3 TxAdd和RxAdd：由PDUType決定其意義，后面的章節與PDUType一並分析；
4 Length: PDU的長度，6 bits，有效范圍 6-37 octets，
5 Payload：取決於PDUType，后面的章節與PDU Type一並分析；
廣播類型的PDU包括 16 bits的header 和（0-31）字節的payload，header中最重要的一個字段是PDU Type, Txaddr, RxAddr以及payload都是由PDU type決定其意義的，現在將PDUType的七種情況展開分析：
根據上圖信息，目前，還有兩個結構沒有展開：AdvData和LLData，
下面以ADV_IND和CONNECT_REQ 為例來展開分析對應PDU
5. ADV_IND PDU展開
ADV_IND PDU
最終，看到AdvData由一個個AD Structure組成，每個advStructure包括三個部分：
· AD length，AD Type 和ADData的長度
· AD Type：AD Data的數據含義，
· AD Data：AD Type所指示的數據
AD type定義在Core Specification Supplement(CSS) v7 https://www.bluetooth.com/specifications/adopted-specifications
先來看從代碼中找到AD type支持的類型：
最后一個AD Type = 0xFF時，可以擴展私有數據。
抓包示例（抓包軟件會解析或者附帶一些的幀頭數據）：
這是工具已經解析了的數據，物理層原始數據如下：
按照PDU結構解析后如下：
SCAN_RSP的原始數據包如下：
解析后：
CONNECT_REQ PDU也是廣播通道上的PDU，我們后續再繼續展開分析。
6. 廣播階段設備的交互流程
一般情況下，廣播階段設備的交互流程如下所所示：
