目錄

創(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版本廣播：

實(shí)現(xiàn)原理：

格式定義：

廣播事件類型：

擴(kuò)展廣播：

周期廣播：

廣播集：

HCI接口定義：

4.2版本：

5.0版本：

周期廣播：

疑問與解答：

---

前言：

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

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

4.2版本廣播：

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

圖1

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

1組：ADV_IND，ADV_DIRECT_IND，ADV_NONCONN_IND，ADV_SCAN_IND

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

圖2

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

圖3

其中需要說明的2點(diǎn)：

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

實(shí)現(xiàn)原理：

4.2版本的藍(lán)牙規(guī)范中，提到過它的廣播通道只有 37，38，39 這三個(gè)，剩余的37個(gè)信道都是數(shù)據(jù)信道，數(shù)據(jù)信道用于發(fā)送連接的數(shù)據(jù)，payload比廣播信道的數(shù)據(jù)要長（從Link Layer packet format來看，可以發(fā)送257個(gè)字節(jié)PDU）。在5.0的廣播信道定義中，將37，38，39三個(gè)信道定義為Primary Advertising，可以叫做主廣播信道，將剩余37個(gè)信道叫做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擴(kuò)展廣播的核心思想，“將廣播數(shù)據(jù)用數(shù)據(jù)信道來傳輸”。

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

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

格式定義：

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

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

圖5

Common Extended Advertising Payload Format格式詳解：

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

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

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

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

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

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

圖6

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

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

圖7

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

• AUX_SYNC_IND：工作在Secondary Advertising上，符合Common Extended Advertising Payload Format的格式，fields的配置選項(xiàng)如圖8。它的作用主要是發(fā)送周期廣播，并且只可以發(fā)送不可連接不可掃描的廣播，不存在ADI，也不存在SyncInfo，如果單包無法將所有的廣播數(shù)據(jù)到AdvData和ACAD中，則可以通過AuxPtr來指向其輔助包來攜帶其他數(shù)據(jù)，它的輔助包是AUX_CHAIN_IND。從GATT的實(shí)現(xiàn)機(jī)制類比來看，AUX_SYNC_IND可以看作是GATT傳輸?shù)腁CL數(shù)據(jù)包。SyncInfo字段，只可能出現(xiàn)在AUX_ADV_IND中，在實(shí)現(xiàn)發(fā)送周期廣播的機(jī)制中，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的配置選項(xiàng)如圖9。它的上級(jí)的數(shù)據(jù)包，可以是 AUX_ADV_IND，AUX_SYNC_IND，AUX_SCAN_RSP或者是另外一個(gè)AUX_CHAIN_IND類型的廣播。

圖9

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

圖10

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

圖11

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

擴(kuò)展廣播 PDU	上級(jí)包 （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我用紅色框標(biāo)注了，從該圖中我們可以看到擴(kuò)展廣播是無法發(fā)送Connectable and Scannable Undirected Event的，只有l(wèi)egacy的廣播可以發(fā)送此類型的廣播事件。而Scannable Undirected Event廣播，legacy和擴(kuò)展廣播都可以發(fā)送。

圖12

擴(kuò)展廣播：

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

• Non-Connectable and Non-Scannable Undirected Event：不可連接不可掃描的非定向廣播，它不響應(yīng)scan_req和connect_req消息，使用擴(kuò)展廣播發(fā)送時(shí)的時(shí)序圖如圖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信道，由上級(jí)包中的AuxPtr指定。

圖13

• Scannable Undirected Event： 可掃描的非定向廣播包，使用擴(kuò)展廣播發(fā)送時(shí)的時(shí)序圖，如圖14，它需要響應(yīng)掃描請(qǐng)求，其中AUX_ADV_IND，AUX_SCAN_REQ，AUX_SCAN_RSP處于同一個(gè)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ā)送，這個(gè)和AUX_ADV_IND PDU不同。

圖14?

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

圖15

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

圖16

限制：

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

周期廣播：

周期廣播是5.0擴(kuò)展廣播的一個(gè)功能，他用來周期的發(fā)送廣播數(shù)據(jù)，同時(shí)它的數(shù)據(jù)是可以變化的，為什么不用非周期廣播來發(fā)送呢（非周期廣播也可以更改數(shù)據(jù)，也可以一直處于廣播狀態(tài)），我的理解是為了低功耗和更好的同步性，因?yàn)榉侵芷趶V播的最小間隔是Adv Interval（20ms）+ delay（0～10ms），因?yàn)閐elay的不確定性，掃描者需要打開更多的掃描窗口來接收到需要的廣播數(shù)據(jù)，同時(shí)它的同步性沒有那么好，但是周期廣播沒有0～10ms的delay，并且使用跳頻技術(shù)，因此掃描者可以更小的打開scan窗口，從而降低功耗，獲得更好的同步性，周期廣播有點(diǎn)類似于單向GATT傳輸，一對(duì)多的GATT連接。當(dāng)周期廣播被啟動(dòng)后，the periodic advertising interval不能被更改。從圖8中，我們可以獲取到周期廣播只能用來發(fā)送不可掃描不可連接的廣播事件。同時(shí)AUX_SYNC_IND如果無法承載全部的AdvData，可以在他后面通過AuxPtr指向下一個(gè)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超過單包大限制，需要跟著若干個(gè)AUX_CHAIN_IND PDU，這個(gè)PDU有點(diǎn)類似于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，它就會(huì)+1，這個(gè)起初讓我很疑惑它是干什么用的，因?yàn)镋vent Counter本身并不出現(xiàn)在AUX_SYNC_IND PDU中，但是它卻會(huì)隨著每次發(fā)送一次AUX_SYNC_IND PDU，它就+1。后來看到了下面這段定義才恍然大悟，原來這個(gè)值是用來計(jì)算跳頻頻譜的，發(fā)起AUX_ADV_IND的周期廣播發(fā)起者，和掃描者，都需要實(shí)時(shí)計(jì)算這個(gè)Event Counter，為了可以獲取下一次接收周期廣播的跳頻后的信道號(hào)。

圖18

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

圖19

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

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

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

廣播集：

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

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

HCI接口定義：

以上內(nèi)容大致解釋了藍(lán)牙5.0的擴(kuò)展廣播的原理和內(nèi)容，實(shí)際使用上還是通過HCI Command和HCI Event來實(shí)現(xiàn)的，因此我們下面介紹一下擴(kuò)展廣播的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：

廣播上報(bào)：

• 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個(gè)廣播集合，但受限于Controller資源，通常這個(gè)值是個(gè)位數(shù)。我們實(shí)際使用時(shí)需要先讀取Controller支持的廣播集合的個(gè)數(shù)，廣播集的索引總是從0x00開始。

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

• LE Set Extended Advertising Parameters Command：設(shè)置廣播參數(shù)，也是針對(duì)指定的廣播集Advertising _Handle進(jìn)行設(shè)置，換句話說，就是每個(gè)廣播集可以設(shè)置單獨(dú)的廣播參數(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會(huì)返回error code?0x0C。

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

• LE Set Extended Advertising Data Command：設(shè)置廣播數(shù)據(jù)，Advertising_Handler表示設(shè)置的廣播集對(duì)應(yīng)的Handle，無論該廣播集的廣播數(shù)據(jù)的發(fā)送是否已經(jīng)enable，該命令都會(huì)執(zhí)行成功，即使enable，也會(huì)在后面更新廣播數(shù)據(jù)，也就是說更新廣播數(shù)據(jù)時(shí)，可以不停止當(dāng)前廣播。Data_Length大0～251個(gè)字節(jié)，表示Data的有效數(shù)據(jù)長度，我們之前提到過擴(kuò)展廣播單次最多可以發(fā)送1650個(gè)字節(jié)的數(shù)據(jù)（通過多個(gè)AUX_CHAIN_IND PDU來實(shí)現(xiàn)），因此如果Data數(shù)據(jù)量大于251時(shí)，這個(gè)hci command會(huì)被調(diào)用多次，一次最多設(shè)置251個(gè)字節(jié)給Controller，也就說1650字節(jié)的數(shù)據(jù)，在HCI層就已經(jīng)開始分包傳輸了，并不是通過HCI Command一次傳輸1650個(gè)字節(jié)的數(shù)據(jù)，Operation就是用來幫助分包HCI數(shù)據(jù)傳輸?shù)模?x00表示中間包，0x01表示第一個(gè)分包，0x02表示最后一個(gè)分包，0x03被用來表示分包結(jié)束或者用來表示legacy adv data，0x04表示沒有數(shù)據(jù)更新，僅僅是告訴Controller去改變ADI field中的DID的值，F(xiàn)ragment_Preference是告訴Controller按照HCI Command下發(fā)的分包方式去分包，還是自行按照最小分包個(gè)數(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)閉的廣播集個(gè)數(shù)，它支持同時(shí)打開/關(guān)閉多個(gè)廣播集的廣播數(shù)據(jù)，Advertising_Handle[i]表示的是具體操作的是哪幾個(gè)廣播集，Duration[i]和Max_Extended_Advertising_Event[i]對(duì)于發(fā)送Mesh廣播來說是一個(gè)特別好的東西，把Host的任務(wù)交給了Controller來更精確的處理。4.2版本的實(shí)現(xiàn)Duration的方式是先Enable Adv，然后Host等待Duration這么久，然后再調(diào)用Disable Adv，并且具體發(fā)送了幾個(gè)Event，完全是根據(jù)AdvInterval和Duration的值粗略的計(jì)算出來的，但是5.0很好的解決了這個(gè)問題，Host調(diào)用一次HCI Command就把Duration和Event的大數(shù)量設(shè)置好了，其中如果Duraion期間內(nèi)，如果Max_Extended_Advertising_Events還沒有發(fā)完的話，則以Duration為準(zhǔn)，停止廣播。如果Duration為0x00，則會(huì)一直發(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í)行的時(shí)間，Period表示掃描任務(wù)的執(zhí)行周期。Period要大于Duration，如果這兩個(gè)值配置為0，則會(huì)一直掃描直到上層調(diào)用disable。

廣播上報(bào)：

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

周期廣播：

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

掃描部分：

• 獲取周期廣播SID：

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

• 同步周期廣播：

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

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

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

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

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

• LE Set Periodic Advertising Parameters Command：設(shè)置周期廣播的廣播參數(shù)，也就是AUX_SYNC_IND的廣播參數(shù)，這里面有一個(gè)很關(guān)鍵的點(diǎn)是這個(gè)Advertising_Handle一定要是一個(gè)已經(jīng)存在的，如果不存在會(huì)返回錯(cuò)誤，也就說周期廣播的發(fā)起，一定要依附于一個(gè)已經(jīng)存在的廣播集。假設(shè)之前已經(jīng)存在一個(gè)廣播集，它的廣播數(shù)據(jù)發(fā)送是這樣的，ADV_EXT_IND，接著是一包AUX_ADV_IND PDU，AUX_ADV_IND它里面包含的SyncInfo field是空的，也就說它不關(guān)聯(lián)任何周期廣播，當(dāng)Host選擇這個(gè)SID來關(guān)聯(lián)周期廣播，Host就調(diào)用LE Set Periodic Advertising Parameters Command來配置這個(gè)SID和本周期廣播進(jìn)行關(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：啟動(dòng)/停止由Advertising_Handle指定的周期廣播，這個(gè)函數(shù)很有意思，如果當(dāng)前周期廣播依附的擴(kuò)展廣播已經(jīng)開啟了，那么這個(gè)Cmd可以觸發(fā)啟動(dòng)周期廣播，如果擴(kuò)展廣播尚未開啟，它就被pending，直到擴(kuò)展廣播啟動(dòng)后（Host發(fā)送LE Set Extended Advertising Enable Command），它接著被啟動(dòng)。另外一點(diǎn)，如果當(dāng)前周期廣播已經(jīng)啟動(dòng)了，然后host停止了擴(kuò)展廣播，沒有停止周期廣播，那么周期廣播還是會(huì)一直發(fā)送的，直到Host調(diào)用了停止周期廣播的HCI Command。這里面可以再回顧一下介紹周期廣播的內(nèi)容，第一個(gè)周期廣播SYNC包需要擴(kuò)展廣播引用出來，但是一旦引用結(jié)束了，理論上就不再需要再次引用了，SYNC包可以一直發(fā)送，但是這種情況會(huì)引入兩個(gè)問題，一個(gè)是后續(xù)打開掃描的設(shè)備，無法檢測(cè)到這個(gè)SYNC包了，因?yàn)樗鼟呙璨坏綌U(kuò)展廣播，無法找到擴(kuò)展廣播指向的SYNC包了，另外一個(gè)問題是晶震的溫漂隨著時(shí)間的流逝積累的越來越大，會(huì)給同步性造成影響，所以理論上應(yīng)該是可行的，但是實(shí)際上應(yīng)該被配置為，幾個(gè)AUX_SYNC_IND包，接著就是一個(gè)指向它的ADV_EXT_IND和AUX_ADV_IND包。

關(guān)于HCI的接口這里面要再重提一下兼容性的問題，5.0版本的藍(lán)牙協(xié)議定義了2套HCI的接口，這兩套接口是可以同時(shí)存在的，一套是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：藍(lán)牙5.0版本的Controller，是否可以與4.2版本的Host兼容。

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

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)站題目：深入理解藍(lán)牙BLE之“擴(kuò)展廣播”-創(chuàng)新互聯(lián)
分享路徑：http://www.rwnh.cn/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)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)