蓝⽛解析（part5）：BLE的⼴播通信
1. 前⾔
⼤家都知道，相⽐传统蓝⽛，蓝⽛低功耗（BLE）最⼤的突破就是加⼤了对⼴播通信（Advertising）的⽀持和利⽤。本⽂将从技术的⾓度，分析和理解BLE协议中有关⼴播通信的定义和实现。
注1：之前的蓝⽛协议分析⽂章（如“”），偏向于从横向、从⼤⽽全的⾓度，介绍蓝⽛协议，以便让⼤家有⼀个整体的认识。⽽从本⽂开始，我们会收敛到⼀个个的功能点上，以功能为出发点，从纵向的⾓度，游⾛于蓝⽛协议的各个层次中，以加深对蓝⽛协议的理解，进⽽达到融会贯通的⽬的。
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，rerved for future u。
TxAdd、RxAdd，由具体的PDU Type决定其意义。
Length，PDU的长度，6 bits，有效范围是6~37 octets。
3.2.2 PDU类型
状态PDU类型PDU格式说明
penang怎么读音
Advertising ADV_IND AdvA(6 octets)
AdvData(0~31 octets)
connectable undirected advertising event，⽤于常规的⼴
播，可携带不超过31bytes的⼴播数据，可被连接，可被扫描：
AdvA，6bytes的⼴播者地址，并由PDU Header的TxAdd bit
里德学院
决定地址的类型（0 public，1 random）；
AdvData，⼴播数据。
ADV_DIRECT_IND AdvA(6 octets)
InitA(6 octets)
connectable directed advertising event，专门⽤于点对点连
接，且已经知道双⽅的蓝⽛地址，不可携带⼴播数据，可被指定的
设备连接，不可被扫描：
AdvA，6bytes的⼴播者地址，并由PDU Header的TxAdd bit
决定地址的类型（0 public，1 random）；
InitA，6bytes的接收者（也是连接发起者）地址，并由PDUtba
Header的RxAdd bit决定地址的类型（0 public，1
random）。
ADV_NONCONN_IND AdvA(6 octets)
AdvData(0~31 octets)
和ADV_IND类似，但不可以被连接，不可以被扫描。dee
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)
parallelism当接收到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的选择
我们在蓝⽛解析(part3)中提到过，BLE可以使⽤40个Physical Channel中的3个作为⼴播通信的物理信道，综合各种因素（抗⼲扰等），最终选取了如下三个：
RF Channel RF Center Frequency Advertising Channel Index
02402MHz37
122426MHz38
392480MHz39
与此同时，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上，回应⼀些请求（如连接请求、扫
designed是什么意思描请求）。并且，⼴播者接收到扫描请求后，需要在同样的Channel上回应。这些过程，也会计算在⼀个Advertising Event
kids是什么意思中。
以上可参考“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的最终结果，就是把接收到的数据（包括Advertir地址、Advertir数据等），反馈给Host。
3.5 Initiating状态
Initiating状态和Scanning状态类似，只不过它的关注点不⼀样：它不关⼼⼴播数据，只关⼼ADV_DIR
ECT_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⾃⾏觉得，并在ret的时候为空，后续可以由Host通过HCI接⼝配置。基于⽩名单，Link Layer可实现多种设备过滤的策略，包括：
Advertising Filter Policy；
Scanner Filter Policy；
Initiator Filter Policy。
具体可参考下⾯的描述。
3.6.2 Advertising Filter Policy
Advertising Filter Policy定义了Advertir（处于Advertising状态）的Link Layer怎么处理SCAN_REQ（扫描请求）和
CONNECT_REQ（连接请求），包括如下策略（Host可以根据实际情况配置，同⼀时刻只能配置⼀种）：
