蓝牙低功耗BLE4.2 简介

通信

提到家庭和工业自动化、物联网(IoT)、可穿戴设备、人机接口设备(HID)众多应用的无线连接协议时，蓝牙一定是首选。为满足各种应用的需求，蓝牙技术联盟(SIG)对蓝牙规格进行了持续改进。发布4.1版大约一年后， SIG在2014年12月蓝牙发布了蓝牙规范4.2版。新的4.2主要包括三项更新 - 低功耗(LE)数据长度扩展(DLE)、链路层(LL)隐私保护以及安全性加强。这些功能提高了BLE数据带宽、隐私保护和安全性，同时还有助于降低功耗。本系列文章将详细讨论这些功能以及它们如何影响系统性能。

　　蓝牙低功耗(BLE)协议栈可以分成三个部分：

　　控制器：协议栈控制器对数据包进行了加密，转换为无线信号发送。在接收时，控制器将对无线信号解码，并重构数据包。

　　主机：主机由管理两个或多个设备相互通信的各种协议和配置文件(安全管理器、属性协议等)组成。

　　应用：可使主机和控制器实现一个特定功能的用例。

链路层(LL)

　　蓝牙4.2的大部分新功能都集中在链路层周围。链路层在建立可靠物理链路和功能中扮演着非常重要的角色，有助于提高BLE协议稳健性和能效。链路层功能包括广播、扫描、创建和维护连接以建立物理链路。在链路层上定义了两个角色：主设备和从设备。

　　数据长度扩展(DLE)

　　数据长度扩展能够使两个BLE设备之间的数据传输更快。为了了解DLE功能，请先让我们来看看链路层上的BLE数据包。下图所示为蓝牙4.0/4.1的链路层数据包结构。

如果我们仔细观察各数据包的开销，将发现存在1个字节的前导、4个字节的访问地址、2个字节的数据头、3个字节的循环冗余检查(CRC)和一个可选的4个字节的消息完整性检查(MIC)。当使用加密时，消息完整性检查(MIC)将与有效负载一起发送。因此，每个包含27个字节数据的加密链路层数据均含有14个字节的开销。现在，让我们来看看蓝牙4.2定义的链路层数据包结构。

相较于旧版本蓝牙规范的27字节，蓝牙4.2中的有效负载量可达到251个字节。每个数据包开销仍然保持不变，即14个字节。然而，该开销现已与多达251个字节相关联，而不是27个字节。这种最小有效负载的变化提高了吞吐量并减少了处理时间。

　　图4所示为当数据需要通过蓝牙4.1和蓝牙4.2从一个设备传输至另一个设备时的吞吐量

在上图中，数据包时间的计算方法如下：

　　数据包时间= 8 *(前导字节的数量+访问地址字节的数量+头字节的数量+有效负载字节的数量+ MIC字节的数量+ CRC字节的数量)/数据速率秒

　　对于接收数据包，不存在有效负载和MIC字节。因此，接收数据包时间为：

　　发送数据包时间= 8 *(1 + 4 + 2 + 3)/ 106 秒

　　=80微秒

　　含27个字节的有效负载的发送数据包时间为：

　　发送数据包时间= 8 *(1 + 4 + 2 + 27 + 4 + 3)/ 106秒

　　=328微秒

　　同样，251个字节的有效负载的发送数据包时间为2120微秒。

　　另外，如上图所示，随着各发送/接收数据包，存在两个相关的帧间间隔(T_IFS)，一个为发送期间，一个为接收期间。如果某个事务的帧数量增加，则该事务的耗时也将成比例地增加。当数据长度功能被启用时，相较于蓝牙4.1，蓝牙4.2在一个帧内打包了更多数据，从而减少了每次事务处理的总时间，并增加了吞吐量(其中，吞吐量 =有效负载尺寸/总时间)。

　　如上图所示，对于蓝牙4.1链路层，最大有效负载尺寸为27个字节(216比特)以及该交易的总时间为708微秒，意味着约 298 kbps的理论吞吐量。

　　而对于4.2链路层，最大有效负载尺寸为251个字节(2008比特)以及总时间为2500微秒，意味着约 784 kbps的理论吞吐量。因此，相较于蓝牙4.1，蓝牙4.2提供了大约2.6倍的更高吞吐量。

　　BLE 4.2允许主设备和从设备之间协商数据长度，还允许不对称的发送和接收有效负载量。有效地利用该功能以及选择合适的接收/发送数据长度对于实现最大吞吐量具有十分重要的意义。

　　让我们考虑这样一个应用：BLE从设备需要将几千字节传输至主设备、从主设备接收空包并且连接间隔为8.75毫秒。假设在以下设置中协商数据长度(从设备)：

　　情景1 – 发送 - 251个字节，接收 - 251字节

　　情景2 – 发送 - 251个字节，接收 - 27字节

　　在情景1中，如图5所示，在第一次接收/发送数据包时，接收有效负载尺寸为0字节以及发送有效负载尺寸为251个字节，耗时2.5毫秒(包括帧间间隔)。第二次接收/发送数据包也是一样的。这两个接收/发送数据包共耗时5毫秒，在此连接间隔内剩下3.85毫秒。在理想情况下，应该在同一连接间隔内存在另一个接收/发送数据包。但是，主设备的调度器不会在此连接间隔内安排另一个接收/发送数据包。这是因为调度器会基于协商的数据长度(本案例中发送/接收的数据长度均为251)来检查发送/接收数据包是否具有足够的时间。如图所示，含有接收和发送有效负载量为251字节的接收和发送数据包需要4.54毫秒。然而，前两个数据包之后的可用时间为3.85毫秒，这导致在本连接间隔内仅2个发送数据包。

在情景2中，在该连接间隔内，调度器仅需要2.64毫秒就可调度一个数据包，因此在8.75毫秒的连接间隔内可以容纳第三个数据包，如图6所示。如图所示，相对于案例1，本案例将提供高于50%的吞吐量

尽管PDU尺寸的选择会影响吞吐量，但还存在对其产生影响的其他因素，比如，连接间隔和最大传输单元(MTU)。

　　数据长度的扩展可通过任何连接设备的控制器来触发。如果两个设备都支持数据长度的扩展功能，则该设备可发送一个获取更新数据长度的请求，而其他设备将通过其自己的参数来做出响应。图7所示为协商进程。

如果一台不支持数据长度扩展功能的设备接收到数据长度的更新请求时，将会返回一个未知的回复。该回复将通知发起请求的设备另一台设备不支持DLE，该设备将继续传输符合蓝牙4.1 PDU尺寸的数据。也就是说，数据长度扩展支持向下兼容。

[color=rgb(51,]