ble 广播包详解.docx
《ble 广播包详解.docx》由会员分享，可在线阅读，更多相关《ble 广播包详解.docx（12页珍藏版）》请在冰豆网上搜索。
ble广播包详解
在使用EN-Dongle捕获和解析广播包之前，我们先了解一下BLE报文的结构，之后，再对捕获的广播包进行分析。
在学习BLE的时候，下面两个文档是极其重要的，这是SIG发布的蓝牙的核心协议和核心协议增补。
∙核心协议Core_v4.2。
∙核心协议增补CSSv6。
虽然这两个文档是蓝牙技术的根本，但是遗憾的是：
通过这两个文档学习蓝牙并不是那么容易的，阅读和理解起来很费力。
尤其是初学者在阅读这两个文档的时候，感觉无从下口。
所以，本文在分析报文的过程中，会明确指出协议文档在什么地方定义了他们，让我们有目的的去查阅协议文档，做到知其然也知其所以然，这样，学习起来就会轻松很多。
1.BLE报文结构
BLE报文结构如下，他由下图所示的各个域组成。
因为有的域的长度超过了一个字节，所以在传输的过程中就涉及到多字节域中哪个字节先传输的问题，BLE报文传输时的字节序和比特序如下：
∙ 字节序：
大多数多字节域是从低字节开始传输的。
注意，并不是所有的多字节域都是从低字节开始传输的。
∙比特序：
各个字节传输时，每个字节都是从低位开始。
图1：
BLE报文结构
1.1前导
前导是一个8比特的交替序列。
他不是01010101就是10101010，取决于接入地址的第一个比特。
∙若接入地址的第一个比特为0：
01010101
∙若接入地址的第一个比特为1：
10101010
接收机可以根据前导的无线信号强度来配置自动增益控制。
1.2 接入地址
接入地址有两种类型：
广播接入地址和数据接入地址。
∙广播接入地址：
固定为0x8E89BED6，在广播、扫描、发起连接时使用。
∙数据接入地址：
随机值，不同的连接有不同的值。
在连接建立之后的两个设备间使用。
对于数据信道，数据接入地址是一个随机值，但需要满足下面几点要求：
1） 数据接入地址不能超过6个连续的“0”或“1”。
2） 数据接入地址的值不能与广播接入地址相同。
3） 数据接入地址的4个字节的值必须互补相同。
4） 数据接入地址不能有超24次的比特翻转（比特0到1或1到0，称为1次比特翻转）。
5） 数据接入地址的最后6个比特需要至少两次的比特翻转。
6） 符合上面条件的有效随机数据接入地址大概有231个。
1.3 报头
1.3.1广播报文报头
报头的内容取决于该报文是广播报文还是数据报文。
广播报文的报头如下图所示：
图2：
广播报文报头
广播报文的报头包含4bit广播报文类型、2bit保留位、1bit发送地址类型和1bit接收地址类型。
1） 广播报文类型
Core_v4.2的2583页描述了广播报文类型，共有7种类型，如下图所示。
图3：
广播报文类型
每种广播报文类型都具有不同的数据格式及行为。
Core_v4.2的2584页的2.3.1节详细的描述了各个广播报文类型，大家可以阅读此章节进一步了解。
2） 发送地址类型和接收地址类型
发送地址类型和接收地址类型指示了设备使用公共地址（PublicAddress）还是随机地址（RandomAddress）。
公共地址和随机地址的长度一样，都包含6个字节共48位。
BLE设备至少要拥有这两种地址类型中的一种，当然也可以同时拥有这两种地址类型。
∙公共地址（PublicAddress）
公共地址由两部分组成，如下图。
公共地址由制造商从IEEE申请，由IEEE注册机构为该制造商分配的机构唯一标识符OUI（OrganizationallyUniqueIdentifier）。
这个地址是独一无二，不能修改的。
Core_v4.2P2576的1.3.1节描述了公共地址。
图4：
公共地址结构
∙随机地址
随机地址有包含两种：
静态地址（StaticDeviceAddress）和私有地址（PrivateDeviceAddress）。
Core_v4.2P2577的1.3.2.1节描述了静态地址。
图5：
静态地址格式
静态地址有如下要求：
a）静态地址的最高2位有效位必须是1。
b） 静态地址最高2位有效位之外的其余部分不能全为0。
c） 静态地址最高2位有效位之外的其余部分不能全为1。
在私有地址的定义当中，又包含了两个子类：
不可解析私有地址（Non-resolvablePrivateAddress）和可解析私有地址（ResolvablePrivateAddress，RPA）。
nRF51822使用的是静态地址，芯片在出厂时已经设置好了48位地址，我们可以从下面两个寄存器读出地址类型和地址。
a） DEVICEADDRTYPE寄存器。
DEVICEADDR[n]寄存器：
包含DEVICEADDR[0]和DEVICEADDR[1]两个寄存器。
图6：
地址类型寄存器
图7：
地址寄存器
1.4 长度
∙广播报文：
长度域包含6个比特，有效值的范围是6~37。
∙ 数据报文：
长度域包含5个比特，有效值的范围是0~31。
广播报文和和数据报文的长度域有所不同，主要原因是：
广播报文除了最多31个字节的数据之外，还必须要包含6个字节的广播设备地址。
6+31=37，所以需要6比特的长度域。
再次强调：
广播时必须要包含6个字节的广播设备地址。
1.5 数据（AdvData）
广播和扫面响应的数据格式如下图所示，由有效数据部分和无效数据部分组成。
图8：
广播和扫描响应的数据格式
1） 有效数据部分：
包含N个ADStructure，每个ADStructure由Length，ADType和ADData组成。
其中：
∙Length：
ADType和ADData的长度。
∙ADType：
指示ADData数据的含义。
问题来了，我们怎么知道有哪些ADType？
他们又表示什么意义？
可以通过下面2种方式查看ADType和他们表示的意义。
∙从官网查询，但是需要是会员才可以查询。
https:
//www.bluetooth.org/Technical/AssignedNumbers/generic_access_profile.htm
∙查看Nordic的SDK中的定义，ADtype的定义在程序的“ble_gap.h”头文件中。
定义如下：
1#defineBLE_GAP_AD_TYPE_FLAGS0x01/** 1.6 校验
BLE采用的是24位CRC校验。
CRC对报头、长度和数据进行计算。
24位CRC的生成多项式如下：
2. 广播包解析
通过上文的描述，我们对BLE广播包有了大致的了解，接下来我们用EN-Dongle捕获一个心率计的广播包，通过对实际广播包的分析来理解BLE报文结构和广播。
广播包捕获实验的硬件连接如下。
图9：
硬件连接
2.1心率计程序下载
2.1.1 下载协议栈
SoftDevice必须使用nRFgoStudio下载，打开nRFgoStudio，切换到“ProgramSoftDevice”选项卡。
点击“Browse…”按钮打开SoftDevice的HEX文件（位于“…\BLE实验\蓝牙协议栈（SoftDevice）目录下的” s110）。
点击“Program”下载程序。
2.1.1 下载应用程序
应用程序可以用nRFgoStudio下载，也可以在MDK中直接下载调试，在这里我们用nRFgoStudio下载。
切换到“ProgramApplication”选项卡。
点击“Browse…”按钮打开应用程序的HEX文件（位于“…\BLE实验\ble_app_beacon\pca10028\s110\arm5\_build”目录下的 nrf51822_xxaa_s110.hex）。
点击“Program”下载程序。
2.2 捕获广播包
按照《蓝牙4.0BLE抓包
（一）》中的描述进行抓包，下面是我们捕获一个心率计的广播包。
图10：
捕获的心率计广播包
图11：
查看广播包传输的数据
2.3分析广播包
为了方便分析，我们先取出这个广播包实际传输的数据，如图9中所示。
心率计完整的广播报文如下：
D6BE898E 40 21 60BF8AB9CDC5 0B094E6F726469635F48524D 03194103 020106 07030D180F180A18 EFA6F0
2.3.1接入地址
D6BE898E：
接入地址，对广播来说是固定值。
注意一下这里的字节序，接入地址传输时是低字节在前的。
2.3.2PDU
q 40：
广播报文报头。
l bit0~bit3是0000，说明广播类型是ADV_IND，即通用广播指示。
l bit7（RxAdd）是0，bit7（TxAdd）是1，说明使用的是随机地址（randomaddress）。
Core_V4.2P2584的2.3.1有详细的描述。
q 21：
长度，表示这个广播的长度是33个字节。
q 9A3F20FB74C5：
设备地址，这里使用的是随机静态地址。
接下来就是广播包最重要的部分了，称之为AdvData，前面我们说过AdvData是N个ADStructure组层成，每个ADStructure的格式都是Length|ADType|ADData组成。
0B094E6F726469635F48524D 03194103 020106 07030D180F180A18
第一个字节0B表示第一个ADStructure的长度是11个字节，即第一个ADStructure是由0B加上紧跟着0B后面的11个字节组成，因此，第一个ADStructure是：
0B094E6F726469635F48524D
表1：
第1个ADStructure的意义
Length
ADType
ADData
0B
09
4E6F726469635F48524D
11字节
ADtype为“完整的本地名称”
程序中定义的为”Nordic_HRM”对应的十六进制就是4E6F726469635F48524D
第2个ADStructure是：
03194103
表2：
第2个ADStructure的意义
Length
ADType
ADData
03
19
4103
3字节
ADtype为“外观特性”
外观特性是一个16位的数值，由SIG定义，用来列举设备的外观样式，指示设备是普通手机，手环什么的。
第3个ADStructure是：
020106
表3：
第3个ADStructure的意义
Length
ADType
ADData
02
01
06
2字节
ADtype为“Flag”
flag说明了物理连接功能，比如有限发现模式，不支持经典蓝牙等。
l bit0:
LE 有限发现模式。
l bit1:
LE 普通发现模式。
l bit2:
不支持 BR/EDR。
l bit3:
对 SameDeviceCapable（Controller） 同时支持 BLE 和 BR/EDR。
l bit4:
对 SameDeviceCapable（Host） 同时支持 BLE 和 BR/EDR。
bit5..7:
预留。
第4个ADStructure是：
07030D180F180A18
表4：
第4个ADStructure的意义
Length
ADType
ADData
07
03
0D180F180A18
7字节
ADtype为“16bitServiceuuid列表”
该设备支持的完整的16bitServiceuuid列表。
l 180D：
HeartRateserviceUUID（心率服务UUID）
l 180F：
BatteryserviceUUID（电池服务UUID）
l 180A：
DeviceInformationserviceUUID（设备信息服务UUID）
16bit UUID：
128位的UUID相当长，设备间为了识别数据的类型需要发送长达16字节的数据。
为了提高传输效率，蓝牙技术联盟（SIG）定义了一个称为“UUID基数”的128位通用唯一识别码，结合一个较短的16位数使用。
二者仍然遵循通用唯一识别码的分配规则，只不过在设备间传输常用的UUID时，只发送较短的16位版本，接收方收到后补上蓝牙UUID基数即可。
蓝牙UUID基数如下：
00000000–0000–1000–8000–008059B34FB
如要发送的16位UUID为0x2A01，完整的128的UUID便是：
00002A01 –0000–1000–8000–008059B34FB
低功耗蓝牙使用的那部分UUID被分为下列几组：
l 0x1800~0x26FF：
用作服务类通用唯一识别码。
l 0x2700~0x27FF：
用于标识计量单位。
l 0x2800~0x28FF：
用于区分属性类型。
l 0x2900~0x29FF：
用作特性描述。
l 0x2A00~0x7FFF：
用于区分特性类型。
在程序的“ble_srv_common.h”文件中定义了16bitservice UUID，如下，当然也可以在SIG官网上查询：
1#defineBLE_UUID_ALERT_NOTIFICATION_SERVICE0x1811/**
升级会员 