深入理解藍牙BLE之“擴展廣播”-創(chuàng)新互聯(lián)

創(chuàng)新互聯(lián)建站主營潛江網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶APP開發(fā)公司,潛江h(huán)5小程序開發(fā)搭建,潛江網(wǎng)站營銷推廣歡迎潛江等地區(qū)企業(yè)咨詢

前言：

4.2版本廣播：

5.0版本廣播：

實現(xiàn)原理：

格式定義：

廣播事件類型：

擴展廣播：

周期廣播：

廣播集：

HCI接口定義：

4.2版本：

5.0版本：

周期廣播：

疑問與解答：

前言：

BLE 5.0的擴展廣播特性，網(wǎng)上的資料很少，我覺得寫一點關(guān)于擴展廣播的內(nèi)容是有意義的。藍牙BLE的4.2版本及其之前版本，有一個很大的限制，就是廣播數(shù)據(jù)的payload太小了，只有31個字節(jié)。原因是廣播物理信道（37，38，39）只有三個，并且大家都在使用，因此無法像數(shù)據(jù)信道那樣，修改信道上傳輸?shù)臄?shù)據(jù)包的大小來解決問題（數(shù)據(jù)信道有一個好處，就是有37個信道，可以跳頻，大家彼此沖突的幾率小，但是廣播信道沒有這個條件）。

為了解決廣播數(shù)據(jù)payload小的這個問題，藍牙BLE在5.0版本中，新增了擴展廣播的特性，包含了廣播集，周期廣播等概念，了解擴展廣播實現(xiàn)機制后，我們可以明顯的感受到一個信息：“5.0擴展廣播的實現(xiàn)是在模仿GATT連接的實現(xiàn)”。

4.2版本廣播：

我們首先回顧一下4.2版本的廣播定義，4.2的藍牙廣播根據(jù)PDU?Type來區(qū)分，一共有7種類型，這7種類型的廣播都是在37，38，39三個無線信道上收發(fā)的。

圖1

將4.2的藍牙廣播分為2組，這樣更方便記憶：

1組：ADV_IND，ADV_DIRECT_IND，ADV_NONCONN_IND，ADV_SCAN_IND

這四個廣播從名字上來區(qū)分，它們更容易理解為的廣播概念（ADV），它們根據(jù)是否可以處理連接請求和掃描請求兩個維度分為四種，如圖2。

圖2

2組：CONNECT_REQ，SCAN_REQ，SCAN_RSP，這三個類型的廣播，是帶有一定功能性的，之所以將它們也劃分到廣播類型中，是因為它們也是在廣播信道上收發(fā)的，藍牙4.2版本的BLE將在BLE廣播信道上發(fā)送的PDU，都分類為廣播數(shù)據(jù)。藍牙BLE4.2版本的鏈路層的廣播PDU的格式匯總?cè)鐖D3，本文主要介紹擴展廣播，因此此部分內(nèi)容一張圖帶過。?

圖3

其中需要說明的2點：

1.廣播PDU的access address是固定的，它的值為0x8E89BED6。

2.Link Layer packet format中的PDU大值是39（2字節(jié)header，37字節(jié)Payload）。

5.0版本廣播：

5.0版本協(xié)議發(fā)布之后，新增廣播類型的叫做extend adv，而將4.2以及之前版本的廣播叫做legacy adv，5.0版本協(xié)議中在4.2的7種廣播類型基礎(chǔ)上，又新增了8種廣播類型的PDU，如圖4。

圖4

實現(xiàn)原理：

4.2版本的藍牙規(guī)范中，提到過它的廣播通道只有 37，38，39 這三個，剩余的37個信道都是數(shù)據(jù)信道，數(shù)據(jù)信道用于發(fā)送連接的數(shù)據(jù)，payload比廣播信道的數(shù)據(jù)要長（從Link Layer packet format來看，可以發(fā)送257個字節(jié)PDU）。在5.0的廣播信道定義中，將37，38，39三個信道定義為Primary Advertising，可以叫做主廣播信道，將剩余37個信道叫做Secondary Advertising，Secondary Advertising也可以用來發(fā)送廣播數(shù)據(jù)，可以叫做輔助廣播信道或者第二廣播信道，說白了就是使用4.2的數(shù)據(jù)信道作為輔助廣播信道，用來發(fā)送廣播數(shù)據(jù)，將單包廣播數(shù)據(jù)的payload提升到和“連接ACL數(shù)據(jù)payload”一樣，輔助廣播信道上發(fā)送和接收的包，也叫做輔助包（auxiliary packet）。這就是5.0擴展廣播的核心思想，“將廣播數(shù)據(jù)用數(shù)據(jù)信道來傳輸”。

將廣播數(shù)據(jù)用數(shù)據(jù)信道來傳輸，確實可以提升單包數(shù)據(jù)的payload，但是也需要解決一個核心問題，對端設(shè)備無法同時在40個信道上掃描廣播包，掃描端設(shè)備必須要確定廣播設(shè)備在什么時候使用了哪個數(shù)據(jù)信道來傳輸廣播數(shù)據(jù)，這個核心問題在BLE的GATT連接通信上也是存在的（它的解決方式是跳頻，跳頻的策略是在“建立連接時由兩端設(shè)備同步Channel Map和hop”的基礎(chǔ)上來實現(xiàn)，然后就可以按照雙方已知的規(guī)則進行跳頻通信）。另外一個核心問題是如何向下兼容4.2版本的廣播實現(xiàn)。

5.0新增的8個廣播類型，7個是工作在Secondary Advertising上的，都是AUX_***命名的廣播，AUX是Auxiliary（輔助）的縮寫，只有一個ADV_EXT_IND是工作在Primary Advertising上。

格式定義：

圖4的表格中，PDU Type為0011b的SCAN_REQ和AUX_SCAN_REQ，這兩個廣播消息的PDU Type是相同的，并且PDU的Payload格式也是相同的，那么藍牙BLE是如何區(qū)分這兩個消息的不同呢，后來一想它們是工作在不同的信道上的，SCAN_REQ工作在37，38，39三個信道，AUX_SCAN_REQ工作在0～36信道，如果一個PDU Type為0011b的廣播消息出現(xiàn)在Primary Advertising上，那么他就是SCAN_REQ，如果出現(xiàn)在Secondary Advertising上，那么他就是AUX_SCAN_REQ消息。CONNECT_IND和AUX_CONNECT_REQ消息也是靠著同樣的邏輯進行區(qū)分的。

剩下6種廣播類型，其中5個工作在Secondary Advertising上，是AUX_SCAN_RESP，AUX_ADV_IND，AUX_SYNC_IND，AUX_CHAIN_IND和AUX_CONNECT_RSP，另外1個工作在Primary Advertising上，叫做ADV_EXT_IND，這6種廣播的payload格式均符合Common Extended Advertising Payload Format格式，如圖5所示，該圖中的Payload部分只列出了擴展廣播相關(guān)的新增的數(shù)據(jù)格式，兼容4.2版本的legacy部分沒有列出（可以參考圖3中的Payload）。

圖5

Common Extended Advertising Payload Format格式詳解：

Extended Header Length：表示Extended Header字段的長度，取值范圍是0～63個字節(jié)。

AdvMode：廣播模式，因為這5個廣播消息的PDU TYPE是0111b或者1000b，無法充分表示可連接，可掃描的特性類型，因此額外增加了這個AdvMode字段來實現(xiàn)legacy adv中的PDU TYPE的功能。并且從圖5中可以了解到，擴展廣播的“PDU TYPE”中，沒有Connectable + Scannable的廣播類型。
Extended Header：由Extended Header Length字段的內(nèi)容是可變長的特性可知，Extended Header的幾個字段不是全部必須存在的。

Extended Header Flags：共占用一個字節(jié)，共8bit，每一位表示對應(yīng)的AdvA～ACAD字段是否存在，AdvA到ACAD正好是8個字段。
AdvA：6字節(jié)，表示發(fā)起廣播設(shè)備的mac地址。
TargetA：6字節(jié)，是該廣播的目的地址。
RFU：預(yù)留字段，5.0的協(xié)議中尚未使用。
AdvDataInfo：共2個字節(jié)。SID占用4個bit，表示廣播集合的ID。DID占用12個字節(jié)，表示的是該集合中，該廣播數(shù)據(jù)的ID。
AuxPtr：共占用3字節(jié)，AuxPtr字段的存在的話，表示一些或所有廣播數(shù)據(jù)存在后續(xù)的輔助廣播包中。Channel Index表示下一個輔助包出現(xiàn)在哪個Secondary Advertising上，Aux Offset表示時間偏移的值，Offset Units表示Aux Offset的計算單位，這兩個值表示下一個輔助包什么時間出現(xiàn)在Secondary Advertising上，AUX PHY字段表示是工作在2M PHY，還是1M PHY，還是coded PHY。CA表示的是晶震時鐘精度。發(fā)送廣播設(shè)備在發(fā)送該包之后，下一包需要在Aux Offset * Offset Units ～（Aux Offset + 1）*Offet Units之間發(fā)送在指定的Secondary Advertising上。如果這個字段存在，則說明后面還有數(shù)據(jù)可以接收，如果不存在，則表示本包廣播的數(shù)據(jù)已經(jīng)發(fā)送結(jié)束了。
SyncInfo：共占用了18個字節(jié)，這個字段是給周期廣播用的，AUX_SYNC_IND和AUX_ADV_IND會涉及這個字段。除了Event Counter之外，其他的幾個字段與legacy的CONNECT_IND字段基本相同，有一個跳頻的ChannelMap，Interval，offset等，周期廣播和GATT的鏈接有著相同的實現(xiàn)邏輯，不過它相對于鏈接的優(yōu)勢是可以一對多，劣勢是數(shù)據(jù)只能單向傳輸。Event Counter包含了paEventCounter的值，在AUX_SYNC_IND會用到（雖然不存在于AUX_SYNC_IND PDU中），我們后面再說。
TXPower：一個字節(jié)，表示發(fā)射功率。
ACAD：Additional Controller Advertising Data的縮寫，ACAD的內(nèi)容和格式與AdvData相同，不同的是ACAD不允許被多個廣播包分包傳輸，它必須是一包傳輸。

AdvData：最終的廣播數(shù)據(jù)，在擴展廣播功能的8種新增的廣播類型中，有的廣播類型的AdvData字段是可以不存在的，這個后面會詳細介紹各種擴展廣播的格式和功能。Controller理論上單次發(fā)送的廣播數(shù)據(jù)最多可以是1650個字節(jié)（實際上要看芯片能力），不過在鏈路層Controller會進行分包傳輸，單包的大小是根據(jù)藍牙芯片的實際性能和資源來定的，好的方案是大程度的增加單包的payload，進而減少分包數(shù)量。如果Host下發(fā)的廣播數(shù)據(jù)已被鏈路層的Controller分包，但是隨后無法傳輸所有分包，則controller會在最后一個分包中的Extended Header字段中的AuxPtr字段的AuxOffset設(shè)置為0，則對端的掃描設(shè)備會了解到分包已被截斷了。

下面詳細介紹一下這幾種新增的廣播包的格式：

AUX_CONNECT_REQ和AUX_SCAN_REQ：這兩個擴展廣播的消息格式與對應(yīng)的4.2版本的legacy廣播一樣，不同的點是legacy廣播工作在Primary Advertising上，擴展廣播的擴展掃描和連接工作在Secondary Advertising上。
ADV_EXT_IND：這個廣播是擴展廣播特性中，唯一一個工作在Primary Advertising上的廣播包，它符合Common Extended Advertising Payload Format的格式，掃描設(shè)備需要先在Primary信道掃描到該消息，然后才可以知道什么時候，去哪個輔助信道掃描，來獲取想要的擴展廣播數(shù)據(jù)。之前提到過Extended Header中的字段，并不是全部field都強制必須存在的，詳細信息如圖6所示。

圖6

從圖6可知，ADV_EXT_IND里面是不帶AdvData和ACAD，說明它本身不包含最終的廣播數(shù)據(jù)。另外with auxiliary packet的廣播類型，一定要包含ADI和AuxPtr字段，ADI標識本廣播屬于哪個廣播集合（SID），廣播數(shù)據(jù)的ID（DID）是多少。AuxPtr會告訴掃描設(shè)備，它的輔助包的廣播數(shù)據(jù)在什么時間點出現(xiàn)在哪個輔助信道上。他的第一個輔助包的格式是AUX_ADV_IND。

AUX_ADV_IND：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項如圖7。

圖7

ADI是強制存在的字段，并且要求和指向它的ADV_EXT_IND中的ADI是相同的，這樣子才可以表示這兩個廣播是關(guān)聯(lián)的，它們協(xié)作起來發(fā)送同一個payload比較大的廣播數(shù)據(jù)。如果數(shù)據(jù)廣播的payload比較短，一個AUX_ADV_IND就可以發(fā)送完成，則它的AuxPtr可以沒有，如果廣播數(shù)據(jù)沒有發(fā)完，則它的AuxPtr字段指向下一個輔助包，它可以是AUX_CHAIN_IND。如果是周期廣播的話，那么它的SyncInfo字段指向下一個AUX_SYNC_IND（周期廣播）。

AUX_SYNC_IND：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項如圖8。它的作用主要是發(fā)送周期廣播，并且只可以發(fā)送不可連接不可掃描的廣播，不存在ADI，也不存在SyncInfo，如果單包無法將所有的廣播數(shù)據(jù)到AdvData和ACAD中，則可以通過AuxPtr來指向其輔助包來攜帶其他數(shù)據(jù)，它的輔助包是AUX_CHAIN_IND。從GATT的實現(xiàn)機制類比來看，AUX_SYNC_IND可以看作是GATT傳輸?shù)腁CL數(shù)據(jù)包。SyncInfo字段，只可能出現(xiàn)在AUX_ADV_IND中，在實現(xiàn)發(fā)送周期廣播的機制中，AUX_ADV_IND可以類比于legacy的CONNECT_REQ，AUX_SYNC_IND可以類比于GATT的ACL數(shù)據(jù)包。

圖8?

AUX_CHAIN_IND：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項如圖9。它的上級的數(shù)據(jù)包，可以是 AUX_ADV_IND，AUX_SYNC_IND，AUX_SCAN_RSP或者是另外一個AUX_CHAIN_IND類型的廣播。

圖9

AUX_SCAN_RESP：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項如圖10。是AUX_SCAN_REQ的回復(fù)包，它的輔助包是AUX_CHAIN_IND。

圖10

AUX_CONNECT_RSP：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項如圖11。

圖11

擴展廣播的spec中，經(jīng)常會出現(xiàn)上級包（superior PDU），輔助包（auxiliary PDU）的概念，我們可以把擴展廣播理解為一個單向鏈表，表頭是工作在Primary Advertising上的ADV_EXT_IND PDU（其中AUX_SCAN*和AUX_CONNECT*除外），它里面的AuxPtr指向了下一個工作在Secondary Advretising上的AUX_ADV_IND PDU，如果有更多的數(shù)據(jù)的話，它里面的AuxPtr還會指向下一個AUX_CHAIN_IND PDU，依次向后，可能會存在n個AUX_CHAIN_IND PDU，直到數(shù)據(jù)結(jié)束，最后一個AUX_CHAIN_IND的AuxPtr字段為空，AuxPtr就像是鏈表里面的next節(jié)點指針。

擴展廣播 PDU	上級包（superior PDU）	輔助包（auxiliary PDU）
ADV_EXT_IND	-	AUX_ADV_IND
AUX_ADV_IND	ADV_EXT_IND	AUX_CHAIN_IND PDU AUX_SYNC_IND PDU
AUX_SYNC_IND	AUX_ADV_IND	AUX_CHAIN_IND
AUX_CHAIN_IND	AUX_ADV_IND AUX_SYNC_IND AUX_CHAIN_IND	AUX_CHAIN_IND
AUX_SCAN_REQ	-	-
AUX_SCAN_RSP	-	AUX_CHAIN_IND
AUX_CONNECT_REQ	-	-
AUX_CONNECT_RSP	-	-

表1

廣播事件類型：

圖12中，描述了5.0版本支持的廣播事件類型，兼容4.2的legacy的PDU Type我用紅色框標注了，從該圖中我們可以看到擴展廣播是無法發(fā)送Connectable and Scannable Undirected Event的，只有l(wèi)egacy的廣播可以發(fā)送此類型的廣播事件。而Scannable Undirected Event廣播，legacy和擴展廣播都可以發(fā)送。

圖12

擴展廣播：

這部分內(nèi)容比較多，我們只選取其中幾個廣播事件類型：

Non-Connectable and Non-Scannable Undirected Event：不可連接不可掃描的非定向廣播，它不響應(yīng)scan_req和connect_req消息，使用擴展廣播發(fā)送時的時序圖如圖13。

? #1 ADV_EXT_IND(Primary Advertising 37,38,39)

? #2 AUX_ADV_IND(Secondary Advertising)

? #3 AUX_CHAIN_IND(Secondary Advertising)

? #4 AUX_CHAIN_IND(Secondary Advertising)

? ......

#n AUX_CHAIN_IND(Secondary Advertising)

? 其中#2～#n處于不同的Secondary信道，由上級包中的AuxPtr指定。

圖13

Scannable Undirected Event：可掃描的非定向廣播包，使用擴展廣播發(fā)送時的時序圖，如圖14，它需要響應(yīng)掃描請求，其中AUX_ADV_IND，AUX_SCAN_REQ，AUX_SCAN_RSP處于同一個Secondary Advertising。掃描設(shè)備在Primary信道監(jiān)聽到ADV_EXT_IND PDU之后，在它的AuxPtr指向的Secondary信道上找到AUX_ADV_IND，然后在該信道上發(fā)送AUX_SCAN_REQ，并在該信道上等待Advertising設(shè)備回復(fù)AUX_SCAN_RSP。AUX_SCAN_REQ和AUX_SCAN_RSP是不需要由ADV_EXT_IND通過AuxPtr指向來的，而是可以直接在Secondary信道上發(fā)送，這個和AUX_ADV_IND PDU不同。

圖14?

Connectable Directed Event：可連接的定向廣播，這個廣播主要用來使用high duty進行快速回連，與掃描一樣，AUX_ADV_IND，AUX_CONNECT_REQ，AUX_CONNECT_RSP是工作在同一個Secondary Advertising上。AUX_CONNECT_REQ雖然工作在Secondary上，但是它不需要ADV_EXT_IND PDU通過AuxPtr指向過來。掃描和連接還涉及了一個失敗重試的問題，依賴兩個參數(shù)backoffCount和upperLimit，退避重試的機制不在這里進行描述了。

圖15

定向和非定向的區(qū)別，主要在于TargetA是否存在，關(guān)于時序部分相差無幾，因此可掃描，可連接，不可掃描不可連接，分別找了1個例子來舉例廣播事件，其中的沒有提到的內(nèi)容還很多，

圖16

限制：

ADV_DIRECT_IND不能用在LE Coded PHY上，但Connectable Directed Event Type的擴展廣播可以用在LE Coded PHY上。
ADV_NONCONN_IND同樣不能用在LE Coded PHY上，對應(yīng)的擴展廣播可以用在LE Codec PHY上。
還有其他限制待補充。

周期廣播：

周期廣播是5.0擴展廣播的一個功能，他用來周期的發(fā)送廣播數(shù)據(jù)，同時它的數(shù)據(jù)是可以變化的，為什么不用非周期廣播來發(fā)送呢（非周期廣播也可以更改數(shù)據(jù)，也可以一直處于廣播狀態(tài)），我的理解是為了低功耗和更好的同步性，因為非周期廣播的最小間隔是Adv Interval（20ms）+ delay（0～10ms），因為delay的不確定性，掃描者需要打開更多的掃描窗口來接收到需要的廣播數(shù)據(jù)，同時它的同步性沒有那么好，但是周期廣播沒有0～10ms的delay，并且使用跳頻技術(shù)，因此掃描者可以更小的打開scan窗口，從而降低功耗，獲得更好的同步性，周期廣播有點類似于單向GATT傳輸，一對多的GATT連接。當周期廣播被啟動后，the periodic advertising interval不能被更改。從圖8中，我們可以獲取到周期廣播只能用來發(fā)送不可掃描不可連接的廣播事件。同時AUX_SYNC_IND如果無法承載全部的AdvData，可以在他后面通過AuxPtr指向下一個AUX_CHAIN_IND PDU。周期廣播的AdvInterval為7.5 ms ~ 81.91875 s。

周期廣播事件的廣播順序應(yīng)該是：

#1：ADV_EXT_IND(Primary Advertising)

#2：AUX_ADV_IND(Secondary Advertising，他的SyncInfo字段不為空，類似于legacy的CONNECT_IND，包含著跳頻所需的ChannelMap)

#3：AUX_SYNC_IND(如果AdvData超過單包大限制，需要跟著若干個AUX_CHAIN_IND PDU，這個PDU有點類似于GATT的ACL連接包，注意他的SyncInfo字段為空)

#4：AUX_SYNC_IND()

#5：AUX_SYNC_IND()

......

圖17

AUX_ADV_IND PDU的SyncInfo field中的Event Counter字段，是這么定義的，每發(fā)一次AUX_SYNC_IND PDU，它就會+1，這個起初讓我很疑惑它是干什么用的，因為Event Counter本身并不出現(xiàn)在AUX_SYNC_IND PDU中，但是它卻會隨著每次發(fā)送一次AUX_SYNC_IND PDU，它就+1。后來看到了下面這段定義才恍然大悟，原來這個值是用來計算跳頻頻譜的，發(fā)起AUX_ADV_IND的周期廣播發(fā)起者，和掃描者，都需要實時計算這個Event Counter，為了可以獲取下一次接收周期廣播的跳頻后的信道號。

圖18

周期廣播傳輸?shù)腁dvData是Host下發(fā)的，鏈路層使用AUX_SYNC_IND PDUs和他的輔助包來發(fā)送數(shù)據(jù)，如果Host不再更新數(shù)據(jù)的話，鏈路層會一直重復(fù)上次的數(shù)據(jù)，周期廣播會一直發(fā)送，直到Host下發(fā)了停止周期廣播的HCI Command。

圖19

圖19對我理解周期廣播的概念造成了很大的困惑，困惑的點在于第二個AUX_SYNC_IND為什么是由ADV_EXT_IND和AUX_ADV_IND引過來的，周期廣播嘛，按理說應(yīng)該沒有他們才對呀，想了很久才想明白，其實第二個ADV_EXT_IND和AUX_ADV_IND是不需要的，沒有它，也可以繼續(xù)發(fā)送周期廣播，它存在的意義是為了讓那些沒有收到第一次ADV_EXT_IND和AUX_ADV_IND的掃描設(shè)備，也可以與當前的周期廣播同步。但是對于第一次就收到了ADV_EXT_IND和AUX_ADV_IND的掃描設(shè)備來說，是沒有什么意義的。掃描者不會嘗試去同步一個已經(jīng)同步的周期廣播。

換個角度說，第一次的ADV_EXT_IND和AUX_ADV_IND確定了AUX_SYNC_IND的廣播時序和跳頻信道，第二次的ADV_EXT_IND和AUX_ADV_IND是為了讓其他掃描設(shè)備也可以同步上AUX_SYNC_IND PDU，它不會更改AUX_SYNC_IND的廣播時序和跳頻信道。之前談到過，周期廣播的實現(xiàn)機制類似于GATT連接，但GATT的單次連接是一對一的，但是周期廣播是希望可以很多掃描者都可以同步獲取廣播上的數(shù)據(jù)的，因此它會發(fā)送多次ADV_EXT_IND和AUX_ADV_IND來保證后面接入的掃描者，也可以同步得獲取數(shù)據(jù)，因此也需要Event Counter這個東西，和前面的內(nèi)容也嚴絲合縫的解釋清楚了。這里面還涉及一個周期廣播Interva和廣播Interval的概念，第一次的ADV_EXT_IND，AUX_ADV_IND和第二次的ADV_EXT_IND，AUX_ADV_IND的間隔是廣播Interval，AUX_SYNC_IND之間的間隔是周期廣播的Interval。

廣播interval >周期廣播interval：每個ADV_EXT_IND之間會有多個AUX_SYNC_IND出現(xiàn)。
廣播interval

廣播集：

廣播集的是擴展廣播中的一個概念，它通過設(shè)置SID和DID，使得藍牙芯片可以插空的“同時”發(fā)送多個不同類型的廣播，比如可以“同時”發(fā)送可連接廣播和不可連接廣播，這樣的功能對于Host的協(xié)議棧代碼實現(xiàn)和Controller的實現(xiàn)有很大的幫助，Controller受限于硬件資源，支持的廣播集的數(shù)量有限，這個需要在實際使用時，詢問芯片原廠。

在4.2版本的藍牙協(xié)議中，如果想要發(fā)送兩個不同類型的廣播數(shù)據(jù)的話，只能在Host層排隊發(fā)送，發(fā)送完第一個類型的廣播之后，再發(fā)送第二個類型的廣播。但是5.0的廣播集的概念，Host可以不用排隊發(fā)送，他們只要設(shè)置為不同的廣播集，Controller會插空的同時發(fā)送兩個類型的廣播，“插空”的意思是在發(fā)送廣播集1的空閑的AdvInterval之間發(fā)送廣播集2。

HCI接口定義：

以上內(nèi)容大致解釋了藍牙5.0的擴展廣播的原理和內(nèi)容，實際使用上還是通過HCI Command和HCI Event來實現(xiàn)的，因此我們下面介紹一下擴展廣播的HCI。

4.2版本：

廣播相關(guān)：

LE Set Advertising Parameters Command：

LE Set Random Address Command：

LE Set Advertising Data Command：

LE Set Scan Response Data Command：

LE Set Advertise Enable Command：

掃描相關(guān)：

LE Set Scan Parameters Command：

LE Set Scan Enable Command：

廣播上報：

LE Advertising Report Event

5.0版本：

新增的5.0廣播相關(guān)的HCI Command：

LE Read Number of Supported Advertising Sets Command：讀取controller支持的廣播集數(shù)量。5.0協(xié)議定義的廣播集的id范圍是0x01～0xF0，共240個廣播集合，但受限于Controller資源，通常這個值是個位數(shù)。我們實際使用時需要先讀取Controller支持的廣播集合的個數(shù)，廣播集的索引總是從0x00開始。

LE Read Maximum Advertising Data Length Command：讀取controller支持的單次發(fā)送的廣播數(shù)據(jù)的大長度（不是單包，而是鏈式廣播的單次）。5.0協(xié)議規(guī)定這個范圍是31～1650，Controller根據(jù)自己的實際資源能力返回這個數(shù)值。

LE Set Extended Advertising Parameters Command：設(shè)置廣播參數(shù)，也是針對指定的廣播集Advertising _Handle進行設(shè)置，換句話說，就是每個廣播集可以設(shè)置單獨的廣播參數(shù)， Advertising_Event_Properties用來控制PDU TYPE，其中bit4=1表示是legacy adv，bit4=0，表示是extend adv，PDU TYPE的具體值在其他bit表示。Advertising_SID的值，就是填寫在ADI field中的值，其他的字段不依次介紹了。如果該廣播集已經(jīng)處于enable的狀態(tài)，調(diào)用次HCI Command，Controller會返回error code?0x0C。

LE Set Advertising Set Random Address Command：設(shè)置廣播PDU的隨機地址，Advertising _Handle表示的是廣播集對應(yīng)的Handler。對比4.2的LE Set Random Address Command可以知道，這兩個hci command就差了一個Advertising_Handle參數(shù)。

LE Set Extended Advertising Data Command：設(shè)置廣播數(shù)據(jù)，Advertising_Handler表示設(shè)置的廣播集對應(yīng)的Handle，無論該廣播集的廣播數(shù)據(jù)的發(fā)送是否已經(jīng)enable，該命令都會執(zhí)行成功，即使enable，也會在后面更新廣播數(shù)據(jù)，也就是說更新廣播數(shù)據(jù)時，可以不停止當前廣播。Data_Length大0～251個字節(jié)，表示Data的有效數(shù)據(jù)長度，我們之前提到過擴展廣播單次最多可以發(fā)送1650個字節(jié)的數(shù)據(jù)（通過多個AUX_CHAIN_IND PDU來實現(xiàn)），因此如果Data數(shù)據(jù)量大于251時，這個hci command會被調(diào)用多次，一次最多設(shè)置251個字節(jié)給Controller，也就說1650字節(jié)的數(shù)據(jù)，在HCI層就已經(jīng)開始分包傳輸了，并不是通過HCI Command一次傳輸1650個字節(jié)的數(shù)據(jù)，Operation就是用來幫助分包HCI數(shù)據(jù)傳輸?shù)模?x00表示中間包，0x01表示第一個分包，0x02表示最后一個分包，0x03被用來表示分包結(jié)束或者用來表示legacy adv data，0x04表示沒有數(shù)據(jù)更新，僅僅是告訴Controller去改變ADI field中的DID的值，F(xiàn)ragment_Preference是告訴Controller按照HCI Command下發(fā)的分包方式去分包，還是自行按照最小分包個數(shù)的方式去自行分包。

LE Set Extended Scan Response Data Command：與LE Set Extended Advertising Data Command的參數(shù)基本一致，設(shè)置SCAN_RSP的Data，它的Operation沒有0x04。

LE Set Extended Advertising Enable Command：開啟或者停止廣播，Number_of_Sets表示打開/關(guān)閉的廣播集個數(shù)，它支持同時打開/關(guān)閉多個廣播集的廣播數(shù)據(jù)，Advertising_Handle[i]表示的是具體操作的是哪幾個廣播集，Duration[i]和Max_Extended_Advertising_Event[i]對于發(fā)送Mesh廣播來說是一個特別好的東西，把Host的任務(wù)交給了Controller來更精確的處理。4.2版本的實現(xiàn)Duration的方式是先Enable Adv，然后Host等待Duration這么久，然后再調(diào)用Disable Adv，并且具體發(fā)送了幾個Event，完全是根據(jù)AdvInterval和Duration的值粗略的計算出來的，但是5.0很好的解決了這個問題，Host調(diào)用一次HCI Command就把Duration和Event的大數(shù)量設(shè)置好了，其中如果Duraion期間內(nèi)，如果Max_Extended_Advertising_Events還沒有發(fā)完的話，則以Duration為準，停止廣播。如果Duration為0x00，則會一直發(fā)送廣播，直到調(diào)用disable adv。

LE Remove Advertising Set Command：刪除指定的廣播集。

LE Clear Advertising Sets Command：清空所有Controller的廣播集。

掃描相關(guān)：

LE Set Extended Scan Parameters Command：

LE Set Extended Scan Enable Command：duplicates是過濾重復(fù)包的策略，Duration表示每次掃描任務(wù)執(zhí)行的時間，Period表示掃描任務(wù)的執(zhí)行周期。Period要大于Duration，如果這兩個值配置為0，則會一直掃描直到上層調(diào)用disable。

廣播上報：

LE Extended Advertising Report Event：相對于4.2的廣播上包相比，5.0的廣播上包內(nèi)容要多出來很多內(nèi)容，首先它可以一次上報多個設(shè)備的廣播數(shù)據(jù)，Num_Reports表示它上包的廣播包個數(shù)，Event_Type表示每個上報的廣播包的PDU TYPE，里面可以有l(wèi)egacy的廣播包，也可以有extend的廣播包，同時bit5～bit6用來幫助分包上報的，01表述后面還有數(shù)據(jù)，10表示數(shù)據(jù)沒有收全，但是后面沒有數(shù)據(jù)了，00表示廣播數(shù)據(jù)已接收完成，如果接收的單次廣播包很大，它也需要多次上傳，Data_Length的大值是229，Advertising_SID表示對應(yīng)的廣播集合ID，用來將分包的數(shù)據(jù)合成一個完整的數(shù)據(jù)，Periodic_Advertising_Interva用來上報接收到的周期廣播的廣播周期（如果Advertising_SID[i]的Data沒有周期廣播的數(shù)據(jù)，則Periodic_Advertising_Interval配置為0x0000，如果有數(shù)據(jù)，除了說明Periodic_Advertising_Interval的值之外，還說明了這個這個SID是周期廣播），其他字段不做詳細介紹。

周期廣播：

周期廣播的原理已經(jīng)介紹過了，通過分析hci的調(diào)用方式，我們可以更加理解它的實現(xiàn)機制。我們分為兩部分來解釋，分為掃描部分和發(fā)送部分。掃描部分又分為獲取周期廣播SID，同步周期廣播，獲取周期廣播的數(shù)據(jù)。

掃描部分：

獲取周期廣播SID：

LE Extended Advertising Report Event里面有一個字段叫做Periodic_Advertising_Interval[i]，除了表示周期廣播Interval之外，還可以表示這個廣播集SID[i]代表著的是一個周期廣播。

同步周期廣播：

然后上層業(yè)務(wù)就可以根據(jù)需要，選擇是否監(jiān)聽這個周期廣播，如果需要監(jiān)聽的話，調(diào)用LE Periodic Advertising Create Sync Command，來通知Controller和這個周期廣播建立同步關(guān)系。同步成功之后，會上報LE Periodic Advertising Sync Established Event事件，表示成功與對方的周期廣播建立了同步關(guān)系，該Event中的Advertising_SID和Sync_Handle，表明了所同步的周期廣播的SID和對應(yīng)的handle，后面Host就可以通過Sync_Handle來操作這個同步接收的任務(wù)。

獲取周期廣播的數(shù)據(jù)：

掃描到的周期廣播的數(shù)據(jù)是通過LE Periodic Advertising Report Event進行上報的（并不是通過LE Extended Advertising Report Event），該Event里面包括了Sync_Handle來表示數(shù)據(jù)來自哪個周期廣播。LE Periodic Advertising Sync Lost Event用來通知Host，與對方的周期廣播已經(jīng)同步失敗了（timeout的時間內(nèi)沒有收到任何AUX_SYNC_IND）。

我推測，如果Host不調(diào)用Periodic Advertising Create Sync Command的話，Controller雖然可以知道有周期廣播存在，但是不會按照周期廣播的ChannelMap去解析它的AUX_SYNC_IND的包，只解析道AUX_ADV_IND，知道它指向一個周期廣播就可以了，這樣子也節(jié)省了掃描的資源，如果每個周期廣播，Controller都去跟隨掃描的話，那么Controller的掃描效率會大打折扣。

創(chuàng)建周期廣播（發(fā)送部分）：

LE Set Periodic Advertising Parameters Command：設(shè)置周期廣播的廣播參數(shù)，也就是AUX_SYNC_IND的廣播參數(shù)，這里面有一個很關(guān)鍵的點是這個Advertising_Handle一定要是一個已經(jīng)存在的，如果不存在會返回錯誤，也就說周期廣播的發(fā)起，一定要依附于一個已經(jīng)存在的廣播集。假設(shè)之前已經(jīng)存在一個廣播集，它的廣播數(shù)據(jù)發(fā)送是這樣的，ADV_EXT_IND，接著是一包AUX_ADV_IND PDU，AUX_ADV_IND它里面包含的SyncInfo field是空的，也就說它不關(guān)聯(lián)任何周期廣播，當Host選擇這個SID來關(guān)聯(lián)周期廣播，Host就調(diào)用LE Set Periodic Advertising Parameters Command來配置這個SID和本周期廣播進行關(guān)聯(lián)。

LE Set Periodic Advertising Data Command：設(shè)置周期廣播的數(shù)據(jù)，Operation字段與LE Set Extended Advertising Data Command中的Operation字段類似，也支持hci命令分包下分段的數(shù)據(jù)，其他字段也類似的功能。

LE Set Periodic Advertising Enable Command：啟動/停止由Advertising_Handle指定的周期廣播，這個函數(shù)很有意思，如果當前周期廣播依附的擴展廣播已經(jīng)開啟了，那么這個Cmd可以觸發(fā)啟動周期廣播，如果擴展廣播尚未開啟，它就被pending，直到擴展廣播啟動后（Host發(fā)送LE Set Extended Advertising Enable Command），它接著被啟動。另外一點，如果當前周期廣播已經(jīng)啟動了，然后host停止了擴展廣播，沒有停止周期廣播，那么周期廣播還是會一直發(fā)送的，直到Host調(diào)用了停止周期廣播的HCI Command。這里面可以再回顧一下介紹周期廣播的內(nèi)容，第一個周期廣播SYNC包需要擴展廣播引用出來，但是一旦引用結(jié)束了，理論上就不再需要再次引用了，SYNC包可以一直發(fā)送，但是這種情況會引入兩個問題，一個是后續(xù)打開掃描的設(shè)備，無法檢測到這個SYNC包了，因為它掃描不到擴展廣播，無法找到擴展廣播指向的SYNC包了，另外一個問題是晶震的溫漂隨著時間的流逝積累的越來越大，會給同步性造成影響，所以理論上應(yīng)該是可行的，但是實際上應(yīng)該被配置為，幾個AUX_SYNC_IND包，接著就是一個指向它的ADV_EXT_IND和AUX_ADV_IND包。

關(guān)于HCI的接口這里面要再重提一下兼容性的問題，5.0版本的藍牙協(xié)議定義了2套HCI的接口，這兩套接口是可以同時存在的，一套是4.2的HCI Command，一套是5.0的新增的HCI Command，但這兩套接口，Host不應(yīng)該攪合起來用，也就說要不你就都用4.2的舊HCI Command，要不你就都用5.0的新HCI Command，LE Set Extended Scan Parameters Command和LE Set Advertise Enable Command這樣的搭配使用是不被允許的。

疑問與解答：

問題1：藍牙5.0版本的Controller，是否可以與4.2版本的Host兼容。

回答：可以，5.0版本的Controller應(yīng)該同時實現(xiàn)4.2版本和5.0版本的HCI Command。與4.2版本的Host一起使用時，使用4.2版本的HCI就可以了，但是這樣就浪費了Controller的5.0的能力。

問題2 ：藍牙4.2版本的controller，是否可以與5.0版本的host兼容。

回答：理論上可以，但需要Host實現(xiàn)的很復(fù)雜，需要Host支持兩套HCI Command，并且更難的是，要根據(jù)不同的Controller版本調(diào)整程序的實現(xiàn)架構(gòu)，所以一般可以不用兼容，更好的方案是直接一個宏定義控制，或者有不同的分支版本來控制兩套代碼。Host可以使用發(fā)送Read Local Version Information Command來讀取Controller的版本，從而選擇不同的HCI?Command和代碼架構(gòu)。

問題3：藍牙5.0版本的controller + host芯片方案，是否可以與對端4.2版本的設(shè)備兼容。

回答：當然是可以的，5.0也可以收發(fā)4.2的廣播包，并且比4.2更高效。

問題4：藍牙5.0版本的controller + host芯片方案，是否可以指定發(fā)送legacy廣播或者extend 廣播。

回答：當然是可以的，可以配置發(fā)送legacy廣播，還是extend廣播，還是周期廣播，可以設(shè)置PDU Type。

問題5：官方SIG Mesh Profile，是否支持通過藍牙5.0版本協(xié)議，發(fā)送大payload的擴展廣播。

回答：Mesh Profile雖然是在5.0協(xié)議發(fā)布之后才發(fā)布的，但是它為了更好的兼容性，加上本身就沒有那么大的控制需求，所以從設(shè)計的角度，就沒有考慮使用擴展廣播發(fā)送大payload的數(shù)據(jù)包，至少1.0版本是如此，即將release的1.1版本也沒有使用到擴展廣播。

問題6：官方SIG Mesh Profile與藍牙5.0版本協(xié)議的關(guān)系。

回答：這個問題可以從兩個角度來看：從協(xié)議設(shè)計的角度來講，可以說沒有什么關(guān)系（1.0版本和1.1版本來看），mesh協(xié)議設(shè)計之初，就考慮到了要兼容4.2版本的藍牙協(xié)議（廣播消息有效的payload只有31個字節(jié)），因此我們現(xiàn)在看到的mesh協(xié)議才是現(xiàn)在這個樣子，mesh協(xié)議為什么需要設(shè)計IV Update的過程，為什么不在每一包mesh消息數(shù)據(jù)都帶著完整的4字節(jié)IV Index或者簡單的增加seq number的字節(jié)數(shù)，一切的一切，都是為了兼容4.2版本的藍牙協(xié)議。如果當時考慮到了使用5.0的擴展廣播上實現(xiàn)SIG Mesh協(xié)議，就不應(yīng)該設(shè)計IV Update的機制。因此可以得出一個結(jié)論，從SIG Mesh release出來的協(xié)議來看，到目前為止，它沒有想過放棄4.2版本藍牙，也沒有考慮使用擴展廣播來發(fā)送Mesh消息，也沒有考慮過通過Mesh協(xié)議發(fā)送長包（目前1.0版本協(xié)議，和即將release的1.1版本協(xié)議，沒有涉及到使用擴展廣播發(fā)送Mesh協(xié)議，但據(jù)說2.0版本的Mesh協(xié)議會涉及一部分擴展廣播的功能，但是只要它不放棄4.2，那么也僅僅是某些功能使用5.0的擴展廣播）。如果有需求希望通過5.0的擴展廣播發(fā)送長包，我建議在5.0的基礎(chǔ)上，重新設(shè)計一套私有的Mesh協(xié)議；從HOST的代碼實現(xiàn)的角度來看，藍牙5.0和Mesh協(xié)議還是有關(guān)系的，因為5.0不僅支持大payload的擴展廣播，也支持多廣播（也就是多廣播集），多廣播這個特性，可以很大程度的簡化Host的mesh協(xié)議相關(guān)的實現(xiàn)，Host可以同發(fā)送SNB和Mesh控制消息，并且可以很方便的設(shè)置發(fā)包個數(shù)和發(fā)包的Duration。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)站題目：深入理解藍牙BLE之“擴展廣播”-創(chuàng)新互聯(lián)
分享路徑：http://bm7419.com/article8/hdeip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、小程序開發(fā)、品牌網(wǎng)站制作、網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、網(wǎng)站內(nèi)鏈

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容