1. 前言
大家都知道，相比傳統藍牙，藍牙低功耗（BLE）最大的突破就是加大了對廣播通信（Advertising）的支持和利用。關於廣播通信，通過“玩轉BLE(1)_Eddystone beacon”和“玩轉BLE(2)_使用bluepy掃描BLE的廣播數據”兩篇文章的介紹，我們已經有了一個整體的認識。本文將依此為基礎，從技術的角度，分析和理解BLE協議中有關廣播通信的定義和實現。
注1：之前的藍牙協議分析文章（如“藍牙協議分析(3)_藍牙低功耗(BLE)協議棧介紹”），偏向於從橫向、從大而全的角度，介紹藍牙協議，以便讓大家有一個整體的認識。
而從本文開始，我們會收斂到一個個的功能點上，以功能為出發點，從縱向的角度，游走於藍牙協議的各個層次中，以加深對藍牙協議的理解，進而達到融會貫通的目的。
2. 概述
2.1 使用場景
在BLE協議中，廣播通信主要有兩類使用場景：
1）單一方向的、無連接的數據通信，數據發送者在廣播信道上廣播數據，數據接收者掃描、接收數據。
2）連接的建立。
后續的分析，將圍繞這兩個使用場景展開。
2.2 協議層次
在BLE協議中，和廣播通信相關的協議層次比較簡單，主要包括：
| GAP-------->HCI-------->LL |
LL(Link Layer)位於最底層，負責廣播通信有關功能的定義和實現，包括物理通道的選擇、相關的鏈路狀態的定義、PDU的定義、設備過濾（Device Filtering）機制的實現等。
HCI負責將LL提供的所有功能，以Command/Event的形式抽象出來，供Host使用。
GAP負責從應用程序的角度，抽象並封裝LL提供的功能，以便讓應用以比較傻瓜的方式進行廣播通信。當然，這不是必須的，也就是說，我們可以在沒有GAP參與的情況下，進行廣播通信。
3. Link Layer
3.1 狀態定義
在某一個時刻，參與廣播通信的BLE設備，從LL的角度看，可以處於如下三種狀態的一種：
| Advertising，數據發送方，周期性的發送廣播數據； Scanning，數據接收方，掃描、接收廣播數據； Initiating，連接發起方，掃描帶有“可連接”標志的廣播數據，一旦發現，則發起連接請求（都是由Link Layer自動完成，不需要Host軟件參與）。 |
3.2 PDU定義
根據應用場景的不同，處於不同狀態的BLE設備，可以發送不同類型的PDU（Packet Data Unit），具體如下。
3.2.1 PDU格式
廣播通信中，傳輸的PDU有如下的格式：
| Header(16bits) | Payload(長度由Header中的“Length”字段決定) |
Header的格式如下：
| PDU Type(4 bits) | RFU(2 bits) | TxAdd(1 bit) | RxAdd(1 bit) | Length(6 bits) | RFU(2 bits) |
| PDU Type，指示PDU的類型，具體可參考后面的介紹。 RFU，reserved for future use。 TxAdd、RxAdd，由具體的PDU Type決定其意義。 Length，PDU的長度，6 bits，有效范圍是6~37 octets。 |
3.2.2 PDU類型
| 狀態 | PDU類型 | PDU格式 | 說明 |
| Advertising | ADV_IND | AdvA(6 octets) AdvData(0~31 octets) |
connectable undirected advertising event， 用於常規的廣播，可攜帶不超過31bytes的廣播數據，可被連接，可被掃描： |
| ADV_DIRECT_IND | AdvA(6 octets) InitA(6 octets) |
connectable directed advertising event， 專門用於點對點連接，且已經知道雙方的藍牙地址，不可攜帶廣播數據，可被指定的設備連接，不可被掃描： |
|
| ADV_NONCONN_IND | AdvA(6 octets) AdvData(0~31 octets) |
和ADV_IND類似，但不可以被連接，不可以被掃描。 | |
| ADV_SCAN_IND | AdvA(6 octets) AdvData(0~31 octets) |
和ADV_IND類似，但不可以被連接，可以被掃描。 | |
| Scanning | SCAN_REQ | ScanA(6 octets) AdvA(6 octets) |
當接收到ADV_IND或者ADV_SCAN_IND類型的廣播數據的時候，可以通過該PDU，請求廣播者廣播更多的信息： ScanA，6bytes的本機地址，並由PDU Header的TxAdd bit決定地址的類型（0 public，1 random）； AdvA，6bytes的廣播者地址，並由PDU Header的RxAdd bit決定地址的類型（0 public，1 random）。 |
| SCAN_RSP | AdvA(6 octets) ScanRspData(0~31 octets) |
廣播者收到SCAN_REQ請求后，通過該PDU響應，把更多的數據傳送給接受者。 AdvA，6bytes的廣播者地址，並由PDU Header的TxAdd bit決定地址的類型（0 public，1 random）； ScanRspData，scan的應答數據。 |
|
| Initiating | CONNECT_REQ | InitA (6 octets) AdvA (6 octets) LLData (22 octets) |
當接收到ADV_IND或者ADV_DIRECT_IND類型的廣播數據的時候，可以通過該PDU，請求和對方建立連接： InitA，6bytes的本機地址，並由PDU Header的TxAdd bit決定地址的類型（0 public，1 random）； AdvA，6bytes的廣播者地址，並由PDU Header的RxAdd bit決定地址的類型（0 public，1 random）； LLData，BLE連接有關的參數信息，具體請參考后續文章的介紹。 |
3.2.3 總結
有關廣播通信的PDU類型，總結如下：
| 1）如果只需要定時傳輸一些簡單的數據（如某一個溫度節點的溫度信息），后續不需要建立連接，則可以使用ADV_NONCONN_IND。廣播者只需要周期性的廣播該類型的PDU即可，接收者按照自己的策略掃描、接收，二者不需要任何額外的數據交互。 2）如果除了廣播數據之外，還有一些額外的數據需要傳輸，由於種種原因，如廣播數據的長度限制、私密要求等，可以使用ADV_SCAN_IND。廣播者在周期性廣播的同時，會監聽SCAN_REQ請求。接收者在接收到廣播數據之后，可以通過SCAN_REQ PDU，請求更多的數據。 3）如果后續需要建立點對點的連接，則可使用ADV_IND。廣播者在周期性廣播的同時，會監聽CONNECT_REQ請求。接收者在接收到廣播數據之后，可以通過CONNECT_REQ PDU，請求建立連接。 4）通過ADV_IND/CONNECT_REQ的組合建立連接，花費的時間比較長。如果雙方不關心廣播數據，而只是想快速建立連接，恰好如果連接發起者又知道對方（廣播者）的藍牙地址（如通過掃碼的方式獲取），則可以通過ADV_DIRECT_IND/CONNECT_REQ的方式。 |
3.3 Advertising狀態
3.3.1 Advertising Channel的選擇
我們在“藍牙協議分析(3)_藍牙低功耗(BLE)協議棧介紹”中提到過，BLE可以使用40個Physical Channel中的3個作為廣播通信的物理信道，綜合各種因素（抗干擾等），最終選取了如下三個：
| RF Channel | RF Center Frequency | Advertising Channel Index |
| 0 | 2402MHz | 37 |
| 12 | 2426MHz | 38 |
| 39 | 2480MHz | 39 |
與此同時，Link Layer允許Host在這這三個物理信道中，任意選取一個或者多個，用於廣播。Link Layer將相同的廣播數據，在每一個被中的Channel中，發送一次。
3.3.2 Advertising Event的定義
由前面的描述可知，BLE廣播的過程中，根據使用場景的不同，會在被使用的每一個物理Channel上，發送（或接收）多種類型的PDU。基於此，BLE協議提出了“Advertising Event”的概念，即：
| Advertising Event是在所有被使用的物理Channel上，發送的Advertising PDU的組合。 |
如果覺得有點繞口的話，我們再用用通俗的語言解釋：
| BLE設備處於Advertising狀態的目的，就是要廣播數據。並且，根據應用場景的不同，可廣播4種類型的數據。 另外，BLE設備最多可以在3個物理Channel上廣播數據。也就是說，同一個數據（4中類型中的一種），需要在多個Channel上依次廣播。因此，這樣依次在多個Channel上廣播的過程，就叫做一個Advertising Event。 與此同時，有些廣播（如可連接、可掃描）發送出去之后，允許接收端在對應的Channel上，回應一些請求（如連接請求、掃描請求）。並且，廣播者接收到掃描請求后，需要在同樣的Channel上回應。這些過程，也會計算在一個Advertising Event中。 |
以上可參考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]” 4.4.2章節中的有關圖示，本文不再詳細介紹了。
3.3.3 Advertising Event Type
根據應用場景的不同（基本對應3.2.3小節所總結的4中場景），BLE協議也規定了不同類型的Advertising Event，包括：
| Connectable Undirected Event； Connectable Directed Event（包括Low Duty Cycle和High Duty Cycle）； Scannable Undirected Event； Non-connectable Undirected Event。 |
不同的Advertising Event，所對應的Advertising參數（如周期等）也不同，具體請參考后面的描述。
3.3.4 Advertising周期的設定
對BLE廣播通信來說，Advertising的周期是一個比較重要的參數，因為它關系到系統的功耗和通信的效率，因此需要根據使用場景，小心設定。
對除High Duty Cycle Connectable Directed Event之外的其它Advertising Event來說，Advertising周期主要由advInterval、advDelay兩個參數決定的，如下圖所示：
圖片1 Advertising周期
| 其中，advInterval是一個可由Host設定的參數：對於Scannable Undirected和Non-connectable Undirected兩種Advertising Event，該值不能小於100ms（從功耗的角度考慮的，也決定了廣播數據的速率）；對於Connectable Undirected和Low Duty Cycle Connectable Directed兩種Advertising Event，該值不能小於20ms（建立連接嘛，要快點）。 advDelay則是一個0~10ms的偽隨機數。 |
High Duty Cycle Connectable Directed Event則是一個比較狂暴的家伙，其Advertising周期不受上面的參數控制，可以小到3.75ms。不過呢，BLE協議也同時規定：Link Layer必須在1.28s內退出這種狂暴狀態。名副其實的短跑冠軍啊！
注2：我們可以從上面的時間信息推斷出，BLE協議對廣播通信的期望，是非常明確的----不在乎速率、只在乎功耗。一般的廣播通信（不以連接為目的），最高速率也就是31byte / 100ms = 2.48kbps。如果再算上可掃描的那段數據，也就是double，4.96kbps。
注3：對於連接來說，如果事先不知道連接發起者的設備地址，則最快的連接速度可能是20ms。如果事先知道地址，使用High Duty Cycle Connectable Directed Event的話，則可能在3.75ms內建立連接。由此可以看出，BLE的連接建立時間，比傳統藍牙少了很多，這也是BLE設備之間不需要保持連接的原因。
3.4 Scanning狀態
3.4.1 scanWindow和scanInterval
Scanning狀態掃描、接收廣播數據的狀態，該狀態的掃描行為是由scanWindow和scanInterval兩個參數覺得的。scanWindow指示一次掃描的時間（即可以理解為RF RX打開的時間），scanInterval指示兩次掃描之間的間隔。如果這兩個參數的值相同，表示連續不停地掃描。
BLE協議規定，scanWindow和scanInterval最大不能超過10.24s，並且scanWindow不能大於scanInterval。
3.4.2 Passive Scanning和Active Scanning
Passive Scanning之所以稱作消極的（Passive），是因為這種掃描模式下，BLE設備只聽不問，也就是說，只接收ADV_DIRECT_IND、ADV_IND、ADV_SCAN_IND、ADV_NONCONN_IND等類型的PDU，並不發送SCAN_REQ。
而Active Scanning，不只認真聽講，還勤於發問（SCAN_REQ），並接收后續的 SCAN_RSP。
這兩種Scanning的最終結果，就是把接收到的數據（包括Advertiser地址、Advertiser數據等），反饋給Host。
3.5 Initiating狀態
Initiating狀態和Scanning狀態類似，只不過它的關注點不一樣：它不關心廣播數據，只關心ADV_DIRECT_IND和ADV_IND兩類消息，並在符合條件的時候，發出CONNECT_REQ，請求建立連接。
3.6 設備過濾機制
從前面的描述可知，BLE的廣播功能，除了速率上面不給力之外，還是比較爽的。但有一個問題，需要引起我們的重視：
| 如果周圍有很多的BLE設備在廣播，對Scanner來說，它的Controller會掃描到很多廣播數據，如果這些數據都上報給Host（甚至用戶）的話，估計Host（或者用戶）會瘋掉。換句話說，垃圾信息太多了，我只想看、只想聽我感興趣的？腫么辦？ |
沒關系，有辦法，基於白名單（White List）機制的設備過濾機制登場了。
3.6.1 白名單（White List）
每一個BLE的Controller，可以保存一個設備列表，通過該列表，可以實現設備過濾的功能。這個列表就稱作白名單（White List），保存了一些BLE設備地址。
白名單的大小由Controller自行覺得，並在reset的時候為空，后續可以由Host通過HCI接口配置。基於白名單，Link Layer可實現多種設備過濾的策略，包括：
| Advertising Filter Policy； Scanner Filter Policy； Initiator Filter Policy。 |
具體可參考下面的描述。
3.6.2 Advertising Filter Policy
Advertising Filter Policy定義了Advertiser（處於Advertising狀態）的Link Layer怎么處理SCAN_REQ（掃描請求）和CONNECT_REQ（連接請求），包括如下策略（Host可以根據實際情況配置，同一時刻只能配置一種）：
| Link Layer只接受位於白名單中的設備的掃描和連接請求（最嚴格）； Link Layer可以接受任何設備的掃描和連接請求（最不嚴格，Controller reset后的默認狀態）； Link Layer可以接受任何設備的掃描請求，但只接受位於白名單中的設備的連接請求； Link Layer可以接受任何設備的連接請求，但只接受位於白名單中的設備的掃描請求。 |
3.6.3 Scanner Filter Policy
Scanner Filter Policy定一個Scanner（處於Scanning狀態）的Link Layer怎么處理廣播數據，包括如下策略：
| Link Layer只處理位於白名單中的設備的廣播數據，並且忽略沒有包括自身地址的connectable Directed advertising packet； Link Layer處理所有設備的廣播數據，並且忽略沒有包括自身地址的connectable Directed advertising packet（Controller reset后的默認狀態）。 |
另外，如果設備支持“Extended Scanner Filter”策略，則可以同時支持如下的策略：
| Link Layer只處理位於白名單中的設備的廣播數據，並且不能忽略InitA地址為“resolvable private address”的connectable Directed advertising packet； Link Layer處理所有設備的廣播數據，並且不能忽略InitA地址為“resolvable private address”的connectable Directed advertising packet。 |
注4：有關resolvable private address，我們會在其它文章中介紹。
3.6.4 Initiator Filter Policy
Initiator Filter Policy定一個Initiator （處於Initiating狀態）的Link Layer怎么處理可連接的廣播數據，包括如下策略：
| Link Layer只處理位於白名單中的設備發送的可連接的廣播包，並在收到的時候發起連接請求； 忽略白名單，Link Layer處理由Host指定的設備所發送的可連接的廣播包，並在收到的時候發起連接請求。 |
4. HCI
Link Layer中廣播通信有關的功能介紹完之后，HCI這一層就簡單了，因為它僅僅是將Link Layer所提供的功能封裝成特定的Command和Event，沒有任何邏輯可言。
開始之前，我們先回憶一下“玩轉BLE(1)_Eddystone beacon”中給出的有關hcitool的例子：
| # enable BLE advertising # set advertising data to Eddystone UUID |
終於可以揭開它們的真面目了！
4.1 HCI Command/Event格式
先簡單介紹一下HCI Command和Event的格式（具體可參考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]” 5.4章節）。
HCI Command的格式如下：
| OCF(10bit) +OGF(6bit) | Parameter Total Length | Parameter1 | Parameter2 | … |
| OCF和OGF共同組成16bit的操作碼（OpCode）； OGF是OpCode Group Field的簡稱，長度是6 bits，代碼該HCI命令所屬的group，對應上面HCI命令中的0x08； OCF是OpCode Command Field的簡稱，代碼特定的HCI命令，對應上面HCI命令中的0x000A/0x0008； Parameter Total Length，指示該Command所有參數的長度； Parameter1、Parameter2、等等，16 bits的參數，由具體的Command決定。 |
注5：這里所描述的Command格式，我們只需要關注OGF、OCF和Parameter即可，因為后續我們主要使用“hcitool cmd”命令進行演示，而hcitool已經幫我們封裝了。
HCI Event的格式如下：
| Event code(8 bits) | Parameter Total Length | Parameter1 | Parameter2 | … |
具體意義不再詳細描述。
4.2 廣播通信相關的HCI Command介紹
本節簡單介紹一下和廣播通信有關的HCI Command，更為詳細的信息，可參考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]” 7.8小節的介紹。
注6：所有BLE相關的HCI Command的OGF都是0x08。
4.2.1 Advertising狀態有關的命令
1）HCI_LE_Set_Advertising_Parameters
| 設置廣播參數，包括Advertising Interval、Advertising Type、本機的地址類型、對端設備的地址類型和地址、所使用的物理Channel的map、Advertising Filter Policy等。 |
2）HCI_LE_Set_Advertising_Data
| 設置廣播數據，OCF為0x0008，Command參數的格式如下： Advertising Data Length(8 bits)， Advertising Data 以上面的例子為例，hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00 不同的顏色，依次代表OGF、OCF、Advertising Data Length、Advertising Data。 |
3）HCI_LE_Set_Scan_Response_Data
| 設置Scan請求時的應答數據，OCF為0x0009，格式和HCI_LE_Set_Advertising_Data一模一樣。 |
4）HCI_LE_Set_Advertise_Enable
| 控制Advertising的使能與否，ICF為0x000a，命令參數包括一個8 bits的“Advertising Enable”，如下： hcitool -i hci0 cmd 0x08 0x000A 01 |
4.2.2 Scanning狀態有關的命令
1）HCI_LE_Set_Scan_Parameters
| 設置scan參數，包括Scan Type、Scan Interval、Scan Window、本機的地址類型、Scanning Filter Policy等。 |
2）HCI_LE_Set_Scan_Enable
| Scan動作的開關，其數據格式和HCI_LE_Set_Advertise_Enable一致。 |
4.2.3 Initiating狀態有關的命令
1）HCI_LE_Create_Connection
| 建立連接，可指定Sca Interval、Scan Window、Initiator Filter Policy、Peer Address Type、Peer Address、Own Address Type等Initiating有關的參數，也可以指定連接相關的參數（這里暫不說明）。 |
2）HCI_LE_Create_Connection_Cancel
| 取消連接。 |
4.2.4 白名單（White List）有關的命令
包括：
| HCI_LE_Read_White_List_Size，獲取BLE Controller的白名單大小； HCI_LE_Clear_White_List，清空白名單； HCI_LE_Add_Device_To_White_List，將設備添加到白名單； HCI_LE_Remove_Device_From_White_List，將設備從白名單移除； |
5. GAP
對於廣播通信而言，GAP主要完成兩個事情：
| 1）將Link Layer的“協議語言”，如Advertising、Scannin、Initiating等，轉換為更為直觀的“人類語言”（當然，要進行一些封裝）。 2）為廣播數據和掃描應答數據，定義一些統一的、規范的格式，以達到互聯互通的目的。 |
5.1 GAP模式定義
上面介紹Link Layer的時候，相信大家對那些術語有些暈暈的了，不過還好，回到Host端之后，熟悉的藍牙術語又回來了。GAP從用戶功能的角度，將Link Layer的各種狀態進行了一次映射，抽象出來了如下的4種模式（只有兩種和廣播通信有關，我們會重點介紹）：
1）Broadcast mode and observation procedure
廣播模式，以及對應的解析過程。處於廣播模式的設備，可發送non-connectable undirected或者scannable undirected兩類advertising events。當然具備相應解析能力的設備，可接收這兩類events。
於此同時，GAP為該模式下的設備定義了兩個角色（GAP role）：Broadcaster和Observer，Broadcaster必須具有“Broadcast mode”能力，Observer必須具有“observation procedure”能力。
注7：大家可能會覺得這些術語有些混亂，理解它們，需要把握一點：GAP是一個profile，profile的首要目的是互聯互通，因此它最擅長的就是角色（role，Broadcaster和Observer）和能力（Broadcast mode 和observation procedure）的定義。任何支持GAP的設備，都要聲明自己支持哪些角色，而profile就要規定，哪種角色必須必備哪種能力。后面其它模式的理解，也遵循該原則。
2）Discovery modes and procedures
發現模式，以及對應的發現過程，用於設備的發現（和傳統藍牙保持一致了）。
GAP為該模式下的設備定義了兩個角色：Peripheral和Central，Peripheral是被發現的設備，Central是主動發現別人的設備。同時，GAP定義了6種和發現有關的能力（不同角色的設備可以根據協議的規定，選擇具備哪些能力）：
| Non-Discoverable mode，不可被發現，設備不會廣播任何數據； Limited Discoverable mode，可被發現（有限的），設備可發送non-connectable、scannable undirected或者connectable undirected三類advertising events。“有限”的意思是，設備只會在有限的一段時間內，廣播數據； General Discoverable mode，可被發現（通用的），和上面的模式類似，不過可以廣播很長一段時間； Limited Discovery procedure ，可執行有限的發現操作，可發現處於“Limited Discoverable mode”的設備； General Discovery procedure ，可執行通用的發現操作，可發現處於“Limited Discoverable mode”和“General Discoverable mode”的設備； Name Discovery procedure，可進行Name的發現操作。如果通過Scanning操作（包括Passive和Active兩種）沒有得到廣播設備的名稱，使用該過程，可以在建立連接之后，再獲取對方的名字。 |
3）Connection modes and procedures
連接模式，已經對應的連接過程，用於設備的連接（和傳統藍牙保持一致）。
所有四種角色的設備，Peripheral、Central、Broadcaster和Observer，都有可能涉及連接有關的模式，具體可參考藍牙spec中有關的定義。
連接有關的模式包括：
| Non-connectable mode，不可被連接的模式，設備可發送non-connectable undirected或者scannable undirected兩類advertising events； Directed connectable mode，可被指定的設備連接，設備只發送Connectable Directed advertising events； Undirected connectable mode，可被連接（不指定設備），設備只發送Connectable undirected advertising events； Auto connection establishment procedure，可自動連接處於directed connectable mode或者undirected connectable mode的設備。自動是指Controller自動，Host只需要發號施令即可； General connection establishment procedure，通用的連接過程，Host需要參與。 Selective connection establishment procedure，建立連接的時候，Host可以指定一些連接參數，后續文章再詳細分析； Direct connection establishment procedure，結合設備過濾機制，只連接特定的設備； Connection parameter update procedure，連接參數的更新，后續在分析； Terminate connection procedure，連接斷開的過程。 |
5.2 廣播數據格式
為了互聯互通的目的，BLE協議為31個bytes的廣播數據和掃描應答數據，定義了詳細的格式，如下：
圖片2：廣播數據和掃描應答數據的格式
| 首先，廣播數據（或者掃描應答數據）由一個一個的AD Structure組成，對於未滿31bytes的其它數據，則填充為0； 每個AD Structure由兩部分組成：1byte的長度信息（Data的長度），和剩余的Data信息； Data信息又由兩部分組成：AD Type（長度不定）指示該AD Structure的類型，以及具體的AD Data。 |
如果僅僅是這些，顯示不出藍牙組織的強大。最關鍵的還是AD Type，BLE協議根據實際的應用場景，定義了各種各樣的AD type，以及相應的數據格式，例如
| Service UUID，指示本設備支持哪些profile； Local Name，指示本設備的名稱； Flags，指示本設備支持Limited Discoverable Mode/General Discoverable Mode的能力，以及BLE、BR/EDR的支持能力； 等等； |
注8：AD Type的定義，可參考“https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile”。
注9：AD Data格式的定義，可參考“CSS(Core Specification Supplement) ”文檔。
最后，結合上面的hcitool cmd的例子，加深一下理解：
02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00
| 02 01 06，是一個AD Structure：Data的長度是02；Data是01 06；AD Type是01（Flags）；AD Data是06，表明支持General Discoverable Mode、不支持BR/EDR。 03 03 aa fe，是一個AD Structure：Data的長度是03；Data是03 aa fe；AD Type是03（16 bits的Service UUID）；AD Data是aa fe，是Eddystone profile的Service UUID。 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是一個AD Structure： Data的長度是17（23bytes）； Data是16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00； AD Type是16（Service Data）； AD Data是aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是Eddystone profile具體的Service Data （可參考“https://github.com/google/eddystone/blob/master/protocol-specification.md”中相關的介紹）。 |
6. 總結
啰哩啰唆記了了這么多，恐怕大家不容易看懂，就當自己的一個學習筆記吧，以后遇到相關的問題，來這篇文章查查應該就可以了。