ble廣播包詳解

1、在使用EN-Dongle捕獲和解析廣播包之前,我們先了解一下BLE報(bào)文的結(jié)構(gòu)，之后，再對(duì)捕獲的廣播包進(jìn)行分析。在學(xué)習(xí) BLE的時(shí)候，下面兩個(gè)文檔是極其重要的，這是 SIG發(fā)布的藍(lán)牙的核心協(xié)議 和核心協(xié)議增補(bǔ),?核心協(xié)議。? 核心協(xié)議增補(bǔ)CSSv6。雖然這兩個(gè)文檔是藍(lán)牙技術(shù)的根本，但是遺憾的是：通過(guò)這兩個(gè)文檔學(xué)習(xí)藍(lán)牙并不是那么容易的， 閱讀和理解起來(lái)很費(fèi)力。尤其是初學(xué)者在閱讀這兩個(gè)文檔的時(shí)候，感覺(jué)無(wú)從下口。所以，本文在分析 報(bào)文的過(guò)程中，會(huì)明確指出協(xié)議文檔在什么地方定義了他們，讓我們有目的的去查閱協(xié)議文檔，做到 知其然也知其所以然，這樣，學(xué)習(xí)起來(lái)就會(huì)輕松很多。報(bào)文結(jié)構(gòu)BLE報(bào)文結(jié)構(gòu)如下，他由下圖

2、所示的各個(gè)域組成。因?yàn)橛械挠虻拈L(zhǎng)度超過(guò)了一個(gè)字節(jié)，所以在傳輸?shù)倪^(guò)程中就涉及到多字節(jié)域中哪個(gè)字節(jié)先傳輸?shù)膯?wèn)題，BLE報(bào)文傳輸時(shí)的字節(jié)序和比特序如下：?字節(jié)序：大多數(shù)多字節(jié)域是從低字節(jié)開(kāi)始傳輸?shù)摹Ｗ⒁?，并不是所有的多字?jié)域都是從低字節(jié)開(kāi)始傳輸?shù)摹?比特序：各個(gè)字節(jié)傳輸時(shí)，每個(gè)字節(jié)都是從低位開(kāi)始。圖1 : BLE報(bào)文結(jié)構(gòu)前導(dǎo)前導(dǎo)是一個(gè)8比特的交替序列。他不是 01010101就是，取決于接入地址的第一個(gè)比特。? 若接入地址的第一個(gè)比特為 0: 01010101? 若接入地址的第一個(gè)比特為 1 :接收機(jī)可以根據(jù)前導(dǎo)的無(wú)線信號(hào)強(qiáng)度來(lái)配置自動(dòng)增益控制。接入地址接入地址有兩種類型：廣播接入地址和數(shù)據(jù)接入地址

3、。?廣播接入地址：固定為0X8E89BED6 ,在廣播、掃描、發(fā)起連接時(shí)使用。?數(shù)據(jù)接入地址：隨機(jī)值，不同的連接有不同的值。在連接建立之后的兩個(gè)設(shè)備間使用。對(duì)于數(shù)據(jù)信道，數(shù)據(jù)接入地址是一個(gè)隨機(jī)值，但需要滿足下面幾點(diǎn)要求：1）數(shù)據(jù)接入地址不能超過(guò)6個(gè)連續(xù)的“0”或“ 1 ”。2）數(shù)據(jù)接入地址的值不能與廣播接入地址相同。3）數(shù)據(jù)接入地址的4個(gè)字節(jié)的值必須互補(bǔ)相同。4）數(shù)據(jù)接入地址不能有超 24次的比特翻轉(zhuǎn)（比特0到1或1到0,稱為1次比特翻轉(zhuǎn)）。5）數(shù)據(jù)接入地址的最后6個(gè)比特需要至少兩次的比特翻轉(zhuǎn)。6）符合上面條件的有效隨機(jī)數(shù)據(jù)接入地址大概有231個(gè)。報(bào)頭廣播報(bào)文報(bào)頭報(bào)頭的內(nèi)容取決于該報(bào)文是廣播報(bào)

4、文還是數(shù)據(jù)報(bào)文。廣播報(bào)文的報(bào)頭如下圖所示： 圖2:廣播報(bào)文報(bào)頭廣播報(bào)文的報(bào)頭包含4bit廣播報(bào)文類型、2bit保留位、1bit發(fā)送地址類型和1bit接收地址類型。1）廣播報(bào)文類型的2583頁(yè)描述了廣播報(bào)文類型，共有7種類型，如下圖所示。圖3:廣播報(bào)文類型每種廣播報(bào)文類型都具有不同的數(shù)據(jù)格式及行為。的2584頁(yè)的節(jié)詳細(xì)的描述了各個(gè)廣播報(bào)文類型，大家可以閱讀此章節(jié)進(jìn)一步了解。2）發(fā)送地址類型和接收地址類型發(fā)送地址類型和接收地址類型指示了設(shè)備使用公共地址（PublicAddress）還是隨機(jī)地址（RandomAddress）。公共地址和隨機(jī)地址的長(zhǎng)度一樣，都包含6個(gè)字節(jié)共48位。BLE設(shè)備至少要擁有

5、這兩種地址類型中的一種，當(dāng)然也可以同時(shí)擁有這兩種地址類型。? 公共地址（PublicAddress）公共地址由兩部分組成，如下圖。公共地址由制造商從IEEE申請(qǐng)，由IEEE注冊(cè)機(jī)構(gòu)為該制造商分配的機(jī)構(gòu)唯一標(biāo)識(shí)符 OUI(OrganizationallyUniqueldentfier)。這個(gè)地址是獨(dú)一無(wú)二，不能修改的的節(jié)描述了公共地址。圖4:公共地址結(jié)構(gòu)? 隨機(jī)地址隨機(jī)地址有包含兩種： 靜態(tài)地址(StaticDeviceAddress )和私有地址(PrivateDeviceAddress ) 的節(jié)描述了靜態(tài)地址。圖5:靜態(tài)地址格式靜態(tài)地址有如下要求：a)靜態(tài)地址的最局2位有效位必須是1 ob)

6、靜態(tài)地址最高2位有效位之外的其余部分不能全為0。c)靜態(tài)地址最高2位有效位之外的其余部分不能全為1。在私有地址的定義當(dāng)中，又包含了兩個(gè)子類：不可解析私有地址(Non-resolvablePrivateAddress )和可解析私有地址(ResolvablePrivateAddress , RPA)。nRF51822使用的是靜態(tài)地址，芯片在出廠時(shí)已經(jīng)設(shè)置好了48位地址，我們可以從下面兩個(gè)寄存器讀出地址類型和地址。a)DEVICEADDRTYPE 寄存器。DEVICEADDRn寄存器：包含 DEVICEADDR0和 DEVICEADDR1兩個(gè)寄存器。圖6:地址類型寄存器圖7:地址寄存器長(zhǎng)度?廣播報(bào)

7、文：長(zhǎng)度域包含6個(gè)比特，有效值的范圍是 637。?數(shù)據(jù)報(bào)文：長(zhǎng)度域包含5個(gè)比特，有效值的范圍是 031。廣播報(bào)文和和數(shù)據(jù)報(bào)文的長(zhǎng)度域有所不同，主要原因是：廣播報(bào)文除了最多31個(gè)字節(jié)的數(shù)據(jù)之外，還必須要包含6個(gè)字節(jié)的廣播設(shè)備地址。6+31=37 ,所以需要6比特的長(zhǎng)度域。再次強(qiáng)調(diào)：廣播時(shí)必須要包含6個(gè)字節(jié)的廣播設(shè)備地址。數(shù)據(jù)(AdvData)廣播和掃面響應(yīng)的數(shù)據(jù)格式如下圖所示，由有效數(shù)據(jù)部分和無(wú)效數(shù)據(jù)部分組成。 圖8:廣播和掃描響應(yīng)的數(shù)據(jù)格式1)有效數(shù)據(jù)部分：包含 N 個(gè) ADStructure ,每個(gè) ADStructure 由 Length , ADType 和 ADData 組成。其中：?

8、 Length : ADType 和 ADData 的長(zhǎng)度。? ADType :指示ADData數(shù)據(jù)的含義。問(wèn)題來(lái)了，我們?cè)趺粗烙心男〢DType他們又表示什么意義可以通過(guò)下面 2種方式查看ADType 和他們表示的意義。?從官網(wǎng)查詢，但是需要是會(huì)員才可以查詢。?查看Nordic的SDK中的定義，ADtype的定義在程序的頭文件中。定義如下：1#define BLE_GAP_AD_TYPE_FLAGS0x01/*<Flagsfordiscoverability.*/ 2#define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE0x

9、02/*<Partiallistof16bitserviceUUIDs.*/ 3#define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE0x03/*<Completelistof16bitserviceUUIDs.*/#define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE0x04/*<Partiallistof32bitser viceUUIDs.*/ 5#define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE0x05/*&l

10、t;Completelistof 32bitserviceUUIDs.*/ 6#define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE0x06/* <Partiallistof128bitserviceUUIDs.*/ 7#define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLE TE0x07/*<Completelistof128bitserviceUUIDs.*/ 8#define BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME 0x08/*<Short

11、localdevicename*/ 9#define BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME0x09/*<Cor pletelocaldevicename.*/ 10#define BLE_GAP_AD_TYPE_TX_POWER_LEVEL0x0A/*<Transmitpowerle vel.*/ 11#define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE0x0D/*<Classofdevicd2#define BLE_GA P_AD_TYPE_SIMPLE_PAIRING_HASH_C0x0E/*<Simple

12、PairingHashC!3#define BLE_GAP_AD_TYPE_ SIMPLE PAIRING RANDOMIZER R0x0F/*<SimplePairingRandomizerR.*/4#define BLE GAP AD TYP E_SECURITY_MANAGER_TK_VALUE0x10/*<SecurityManagerTKValue5#define BLE_GAP_AD_TYPE_ SECURITY_MANAGER_OOB_FLAGS0x11/*<SecurityManagerOutOfBandFlagS6#define BLE_GAP_ADTYPE

13、 SLAVE CONNECTION INTERVAL RANGE0x12/*<SlaveConnectionIntervalRange7#define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT0x14/*<Listof16-bitServiceSolicitationU UIDs.*/ 18#define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT0x15/*<Listof128-bitSe rviceSolicitationUUIDs.*/ 19#define BLE_GAP

14、_AD_TYPE_SERVICE_DATA0x16/*<ServiceData-16- bitUUID.*/ 20#define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS0x17/*<PublicTargetAddress* / 21#define BLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS0x18/*<RandomTargetAdd#dSsfi*/ eBLE_GAP_AD_TYPE_APPEARANCE0x19/*<Appearan2e#define BLE_GAP_AD_TYPE_ADVERTISIN

15、G_ INTERVAL0x1A/*<AdvertisingInterval.*/ 24#define BLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_AD DRESS0x1B/*<LEBluetoothDeviceAddress.*/ 25#define BLE_GAP_AD_TYPE_LE_ROLE0x1C/*<LERol e.*/ 26#define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C2560x1D/*<SimplePairingHashC-256.* / 27#define BLE_GAP_AD_TY

16、PE_SIMPLE_PAIRING_RANDOMIZER_R2560x1E/*<SimplePairingRandomiz erR-256.*/ 28#define BLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID0x20/*<ServiceData-32-bitU UID.*/ 29#define BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID0x21/*<ServiceData-128-bitUUI D.*/ 30#define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA0x3D/

17、*<3DInformationDa31#define BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA0xFF/*<ManufacturerSpecficData.*/ 校驗(yàn)BLE采用的是24位CRC校驗(yàn)。CRC對(duì)報(bào)頭、長(zhǎng)度和數(shù)據(jù)進(jìn)行計(jì)算。24位CRC的生成多項(xiàng)式如下：2.廣播包解析通過(guò)上文的描述，我們對(duì) BLE廣播包有了大致的了解，接下來(lái)我們用EN-Dongle 捕獲一個(gè)心率計(jì)的廣播包，通過(guò)對(duì)實(shí)際廣播包的分析來(lái)理解 BLE報(bào)文結(jié)構(gòu)和廣播。廣播包捕獲實(shí)驗(yàn)的硬件連接如下。圖9:硬件連接 心率計(jì)程序下載下載協(xié)議棧SoftDevice 必須使用 nRF

18、goStudio 下載，打開(kāi) nRFgoStudio ,切換至U "ProgramSoftDevice ”選項(xiàng)卡。點(diǎn)擊“Browse”按鈕打開(kāi)SoftDevice的HEX文件(位于“BLE實(shí)驗(yàn) 藍(lán)牙協(xié)議棧(SoftDevice)目錄下的“ s110)。點(diǎn)擊"Program ”下載程序。下載應(yīng)用程序應(yīng)用程序可以用nRFgoStudio 下載，也可以在MDK中直接下載調(diào)試，在這里我們用nRFgoStudio下載。切換到"ProgramApplication ” 選項(xiàng)卡。點(diǎn)擊“Browse”按鈕打開(kāi)應(yīng)用程序的HEX文件(位于“BLE實(shí)驗(yàn)_build ”目錄下的)。點(diǎn)擊

19、“Program”下載程序。捕獲廣播包按照«»中的描述進(jìn)行抓包，下面是我們捕獲一個(gè)心率計(jì)的廣播包。圖10:捕獲的心率計(jì)廣播包圖11 :查看廣播包傳輸?shù)臄?shù)據(jù)分析廣播包為了方便分析，我們先取出這個(gè)廣播包實(shí)際傳輸?shù)臄?shù)據(jù)，如圖 9中所示。心率計(jì)完整的廣播報(bào)文如下：D6BE898E 40 21 60BF8AB9CDC5 0B094E6F5F48524D03194103 020106 07030D180F180A18EFA6F0接入地址D6BE898E :接入地址，對(duì)廣播來(lái)說(shuō)是固定值。注意一下這里的字節(jié)序，接入地址傳輸時(shí)是低字節(jié)在前的。:廣播報(bào)文報(bào)頭。lbit0bit3 是0000 ,

20、說(shuō)明廣播類型是 ADV_IND ,即通用廣播指示。lbit7(RxAdd) 是0, bit7(TxAdd)是1,說(shuō)明使用的是隨機(jī)地址 (randomaddress)。的有詳細(xì)的描述。q21 :長(zhǎng)度，表示這個(gè)廣播的長(zhǎng)度是33個(gè)字節(jié)。q9A3F20FB74C5 :設(shè)備地址，這里使用的是隨機(jī)靜態(tài)地址。接下來(lái)就是廣播包最重要的部分了，稱之為 AdvData ,前面我們說(shuō)過(guò) AdvData是N個(gè)ADStructure組層成，每個(gè)ADStructure 的格式都是Length|ADType|ADData 組成。0B094E6F5F48524D03194103 020106 07030D180F180A18

21、第一個(gè)字節(jié)0B表示第一個(gè)ADStructure 的長(zhǎng)度是11個(gè)字節(jié)，即第一個(gè)ADStructure 是由0B加上緊跟著0B后面的11個(gè)字節(jié)組成，因此，第一個(gè) ADStructure 是：0B094E6F5F48524D表1:第1個(gè)ADStructure 的意義Length ADTypeADData0B094E6F5F48524D11字節(jié)ADtype為“完整的本地名稱”程序中定義的為“ Nordic_HRM對(duì)應(yīng)的十六進(jìn)制就是4E6F5F48524D第 2 個(gè) ADStructure 是：03194103表2:第2個(gè)ADStructure 的意義LengthADTypeADData03194103

22、3字節(jié)ADtype為“外觀特性”外觀特性是一個(gè)16位的數(shù)值，由SIG定義，用來(lái)列舉設(shè)備的外觀樣式， 才旨示設(shè)備是普通手機(jī)，手環(huán)什么的。第 3 個(gè) ADStructure 是：020106表3:第3個(gè)ADStructure 的意義LengthADTypeADData0201062字節(jié)ADtype 為“Flag ”flag說(shuō)明了物理連接功能，比如有限發(fā)現(xiàn)模式，不支持經(jīng)典藍(lán)牙等。lbit0:LE有限發(fā)現(xiàn)模式。bit1:LE普通發(fā)現(xiàn)模式。bit2:不支持 BR/EDR。bit3:對(duì) SameDeviceCapable（Controller）同時(shí)支持 BLE 和 BR/EDR。bit4:對(duì) SameDe

23、viceCapable（Host） 同時(shí)支持 BLE 和 BR/EDR。bit5.7:預(yù)留。第 4 個(gè) ADStructure 是：07030D180F180A18表4:第4個(gè)ADStructure 的意義LengthADTypeADData07030D180F180A187字節(jié)ADtype 為 " 16bitServiceuuid列表”該設(shè)備支持的完整的16bitServiceuuid 列表。l180D : HeartRateserviceUUID（ 心率服務(wù) UUID）l180F: BatteryserviceUUID（ 電池服務(wù) UUID）l180A : DeviceInfor

24、mationserviceUUID（設(shè)備信息服務(wù)UUID）16bitUUID :128位的UUID相當(dāng)長(zhǎng)，設(shè)備間為了識(shí)別數(shù)據(jù)的類型需要發(fā)送長(zhǎng)達(dá)16字節(jié)的數(shù)據(jù)。為了提高傳輸效率，藍(lán)牙技術(shù)聯(lián)盟（SIG）定義了一個(gè)稱為“UUID基數(shù)”的128位通用唯一識(shí)別碼，結(jié)合一個(gè)較短的16位數(shù)使用。二者仍然遵循通用唯一識(shí)別碼的分配規(guī)則，只不過(guò)在設(shè)備間傳輸常用的UUID時(shí)，只發(fā)送較短的16位版本，接收方收到后補(bǔ)上藍(lán)牙UUID基數(shù)即可。藍(lán)牙UUID基數(shù)如下：00000000 -0000 T000 -8000 -008059B34FB如要發(fā)送的16位UUID為0x2A01 ,完整的128的UUID便是：0000 2A

25、01 -0000 -1000 -8000 -008059B34FB低功耗藍(lán)牙使用的那部分 UUID被分為下列幾組：l0x18000x26FF :用作服務(wù)類通用唯一識(shí)別碼。l0x27000x27FF :用于標(biāo)識(shí)計(jì)量單位。l0x28000x28FF :用于區(qū)分屬性類型。l0x29000x29FF :用作特性描述。l0x2A000x7FFF :用于區(qū)分特性類型。在程序的文件中定義了 16bitserviceUUID ,如下，當(dāng)然也可以在 SIG官網(wǎng)上查詢：1#define BLE_UUID_ALERT_NOTIFICATION_SERVICE0x1811/*<AlertNotification

26、serviceUUID.*/ 2 #define BLE_UUID_BATTERY_SERVICE0x180F/*<BatteryserviceUUID.*3#define BLE_UUID_BLOOD_ PRESSURE_SERVICE0x1810/*<BloodPressureserviceUUID.*/4#define BLE_UUID_CURRENT_TIME_SE RVICE0x1805/*<CurrentTimeserviceUUID.*/ 5#define BLE_UUID_CYCLING_SPEED_AND_CADENCE0x1 816/*<CyclingSpeedandCadenceserviceUUID.*/ 6#define BLE_UUID_DEVICE_INFORMATION_SERVIC E0x180A/*<DeviceInformationserviceUUID.*/ 7#define BLE_UUID_GLUCOSE_SERVICE0x1808/*<G lucoseserviceUUID.*/ 8#define BLE_UUID_HEALTH_THERMOMETER_SERVICE0x1809/*<HealthThe