<aside> ✏️
<aside> ✏️
我們需要先說明兩個狀態:
可掃描的 (Scannable):Rx 看到我的 Adv 包,可以發 SCAN_REQ
或 AUX_SCAN_REQ
請求掃描
可連接的 (Connectable):Rx 看到我的 Adv 包,可以發 CONNECT_IND
或 AUX_CONNECT_REQ
請求連線
四種 Legacy Adv PDU 可這樣區分:
Scannable | Non-scannable | |
---|---|---|
Connectable | ADV_IND |
ADV_DIRECT_IND |
Non-connectable | ADV_SCAN_IND |
ADV_NONCONN_IND |
ADV_IND
ADV_DIRECT_IND
ADV_NONCONN_IND
ADV_SCAN_IND
</aside>
<aside> ✏️
ADV_EXT_IND
告訴 Rx 我們即將要遷移到特定 ChannelAUX_ADV_IND
提供 Rx 更多資訊ADV_EXT_IND
AUX_ADV_IND
AUX_SYNC_IND
AUX_CHAIN_IND
AUX_SYNC_SUBEVENT_IND
AUX_SYNC_SUBEVENT_RSP
</aside>
<aside> ✏️
<aside> 📜
這裡是關於 DBAF 的發展動機: </aside>
在 LE v6.0 時,Extended Advertising PDU 新增了一個特別的 PDU type - ADV_DECISION_IND
ADV_DECISION_IND
被用在 Decision-Based Advertising Filtering (DBAF),作為 ADV_EXT_IND
的補充版
作為 ADV_EXT_IND
的補充版,ADV_DECISION_IND
的 aux 包也只能是 AUX_ADV_IND
,並且是在 Secondary Channel
ADV_DECISION_IND
的 Common Extended Advertising Payload Format 和其他人不太一樣:
ADV_DECISION_IND
的 Extended Header 規則目前還算不複雜,雖然有三種 AdvMode (非定向的 NS&NC、C、S),但規則都一樣: