ble 广播播送包详解

...wd......wd......wd...在使用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的节描述了静态地址。

图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和他们表示的意义。从官网查询，但是需要是会员才可以查询。s:///Technical/AssignedNumbers/generic_access_profile.htm查看Nordic的SDK中的定义，ADtype的定义在程序的“ble_gap.h〞头文件中。定义如下：1#defineBLE_GAP_AD_TYPE_FLAGS0x01/**<Flagsfordiscoverability.*/2#defineBLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE0x02/**<Partiallistof16bitserviceUUIDs.*/3#defineBLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE0x03/**<Completelistof16bitserviceUUIDs.*/4#defineBLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE0x04/**<Partiallistof32bitserviceUUIDs.*/5#defineBLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE0x05/**<Completelistof32bitserviceUUIDs.*/6#defineBLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE0x06/**<Partiallistof128bitserviceUUIDs.*/7#defineBLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE0x07/**<Completelistof128bitserviceUUIDs.*/8#defineBLE_GAP_AD_TYPE_SHORT_LOCAL_NAME0x08/**<Shortlocaldevicename.*/9#defineBLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME0x09/**<Completelocaldevicename.*/10#defineBLE_GAP_AD_TYPE_TX_POWER_LEVEL0x0A/**<Transmitpowerlevel.*/11#defineBLE_GAP_AD_TYPE_CLASS_OF_DEVICE0x0D/**<Classofdevice.*/12#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C0x0E/**<SimplePairingHashC.*/13#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R0x0F/**<SimplePairingRandomizerR.*/14#defineBLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE0x10/**<SecurityManagerTKValue.*/15#defineBLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS0x11/**<SecurityManagerOutOfBandFlags.*/16#defineBLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE0x12/**<SlaveConnectionIntervalRange.*/17#defineBLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT0x14/**<Listof16-bitServiceSolicitationUUIDs.*/18#defineBLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT0x15/**<Listof128-bitServiceSolicitationUUIDs.*/19#defineBLE_GAP_AD_TYPE_SERVICE_DATA0x16/**<ServiceData-16-bitUUID.*/20#defineBLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS0x17/**<PublicTargetAddress.*/21#defineBLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS0x18/**<RandomTargetAddress.*/22#defineBLE_GAP_AD_TYPE_APPEARANCE0x19/**<Appearance.*/23#defineBLE_GAP_AD_TYPE_ADVERTISING_INTERVAL0x1A/**<AdvertisingInterval.*/24#defineBLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS0x1B/**<LEBluetoothDeviceAddress.*/25#defineBLE_GAP_AD_TYPE_LE_ROLE0x1C/**<LERole.*/26#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C2560x1D/**<SimplePairingHashC-256.*/27#defineBLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R2560x1E/**<SimplePairingRandomizerR-256.*/28#defineBLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID0x20/**<ServiceData-32-bitUUID.*/29#defineBLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID0x21/**<ServiceData-128-bitUUID.*/30#defineBLE_GAP_AD_TYPE_3D_INFORMATION_DATA0x3D/**<3DInformationData.*/31#defineBLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA0xFF/**<ManufacturerSpecificData.*/

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

2160BF8AB9CDC50B094E6F726469635F48524D

0319410302010607030D180F180A18

EFA6F02.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

0319410302010607030D180F180A18第一个字节0B表示第一个ADStructure的长度是11个字节，即第一个ADStructure是由0B加上紧跟着0B后面的11个字节组成，因此，第一个ADStructure是：0B094E6F726469635F48524D

表1：第1个ADStructure的意义LengthADTypeADData0B094E6F726469635F48524D11字节ADtype为“完整的本地名称〞程序中定义的为〞Nordic_HRM〞对应的十六进制就是4E6F726469635F48524D第2个ADStructure是：03194103

表2：第2个ADStructure的意义LengthADTypeADData031941033字节ADtype为“外观特性〞外观特性是一个16位的数值，由SIG定义，用来列举设备的外观样式，指示设备是普通手机，手环什么的。第3个ADStructure是：020106

表3：第3个ADStructure的意义LengthADTypeADData0201062字节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的意义LengthADTypeADData07030D180F180A187字节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/**<AlertNotificationserviceUUID.*/2#defineBLE_UUID_BATTERY_SERVICE0x180F/**<BatteryserviceUUID.*/3#defineBLE_UUID_BLOOD_PRESSURE_SERVICE0x1810/**<BloodPressureserviceUUID.*/4#defineBLE_UUID_CURRENT_TIME_SERVICE0x1805/**<CurrentTimeserviceUUID.*/5#defineBLE_UUID_CYCLING_SPEED_AND_CADENCE0x1816/**<CyclingSpeedandCadenceserviceUUID.*/6#defineBLE_UUID_DEVICE_INFORMATION_SERVICE0x180A/**<DeviceInformationserviceUUID.*/7#defineBLE_UUID_GLUCOSE_SERVICE0x1808/**<GlucoseserviceUUID.*/8#defineBLE_UUID_HEALTH_THERMOMETER_SERVICE0x1809/**<HealthThermometerserviceUUID.*/9#defineBLE_UUID_HEART_RATE_SERVICE