ble 廣播播送包詳解

...wd......wd......wd...在使用EN-Dongle捕獲和解析播送包之前，我們先了解一下BLE報文的構造，之后，再對捕獲的播送包進展分析。在學習BLE的時候，下面兩個文檔是極其重要的，這是SIG發(fā)布的藍牙的核心協(xié)議和核心協(xié)議增補。核心協(xié)議Core_v4.2。核心協(xié)議增補CSSv6。雖然這兩個文檔是藍牙技術的基本，但是遺憾的是：通過這兩個文檔學習藍牙并不是那么容易的，閱讀和理解起來很費力。尤其是初學者在閱讀這兩個文檔的時候，感覺無從下口。所以，本文在分析報文的過程中，會明確指出協(xié)議文檔在什么地方定義了他們，讓我們有目的的去查閱協(xié)議文檔，做到知其然也知其所以然，這樣，學習起來就會輕松很多。1.BLE報文構造BLE報文構造如下，他由以以以下圖所示的各個域組成。因為有的域的長度超過了一個字節(jié)，所以在傳輸?shù)倪^程中就涉及到多字節(jié)域中哪個字節(jié)先傳輸?shù)膯栴}，BLE報文傳輸時的字節(jié)序和比特序如下：

字節(jié)序：大多數(shù)多字節(jié)域是從低字節(jié)開場傳輸?shù)摹Ｗ⒁?，并不是所有的多字?jié)域都是從低字節(jié)開場傳輸?shù)摹１忍匦颍焊鱾€字節(jié)傳輸時，每個字節(jié)都是從低位開場。

圖1：BLE報文構造1.1前導前導是一個8比特的交替序列。他不是01010101就是10101010，取決于接入地址的第一個比特。假設接入地址的第一個比特為0：01010101假設接入地址的第一個比特為1：10101010接收機可以根據(jù)前導的無線信號強度來配置自動增益控制。1.2

接入地址接入地址有兩種類型：播送接入地址和數(shù)據(jù)接入地址。播送接入地址：固定為0x8E89BED6，在播送、掃描、發(fā)起連接時使用。數(shù)據(jù)接入地址：隨機值，不同的連接有不同的值。在連接建設之后的兩個設備間使用。對于數(shù)據(jù)信道，數(shù)據(jù)接入地址是一個隨機值，但需要滿足下面幾點要求：

1)

數(shù)據(jù)接入地址不能超過6個連續(xù)的“0〞或“1〞。

2)

數(shù)據(jù)接入地址的值不能與播送接入地址一樣。

3)

數(shù)據(jù)接入地址的4個字節(jié)的值必須互補一樣。

4)

數(shù)據(jù)接入地址不能有超24次的比特翻轉(比特0到1或1到0，稱為1次比特翻轉)。

5)

數(shù)據(jù)接入地址的最后6個比特需要至少兩次的比特翻轉。

6)

符合上面條件的有效隨機數(shù)據(jù)接入地址大概有231個。1.3

報頭1.3.1播送報文報頭報頭的內(nèi)容取決于該報文是播送報文還是數(shù)據(jù)報文。播送報文的報頭如以以以下圖所示：

圖2：播送報文報頭播送報文的報頭包含4bit播送報文類型、2bit保存位、1bit發(fā)送地址類型和1bit接收地址類型。

1)

播送報文類型Core_v4.2的2583頁描述了播送報文類型，共有7種類型，如以以以下圖所示。

圖3：播送報文類型每種播送報文類型都具有不同的數(shù)據(jù)格式及行為。Core_v4.2的2584頁的2.3.1節(jié)詳細的描述了各個播送報文類型，大家可以閱讀此章節(jié)進一步了解。

2)

發(fā)送地址類型和接收地址類型發(fā)送地址類型和接收地址類型指示了設備使用公共地址(PublicAddress)還是隨機地址(RandomAddress)。公共地址和隨機地址的長度一樣，都包含6個字節(jié)共48位。BLE設備至少要擁有這兩種地址類型中的一種，當然也可以同時擁有這兩種地址類型。公共地址(PublicAddress)公共地址由兩局部組成，如以以以下圖。公共地址由制造商從IEEE申請，由IEEE注冊機構為該制造商分配的機構唯一標識符OUI(OrganizationallyUniqueIdentifier)。這個地址是獨一無二，不能修改的。Core_v4.2P2576的1.3.1節(jié)描述了公共地址。

圖4：公共地址構造隨機地址隨機地址有包含兩種：靜態(tài)地址〔StaticDeviceAddress〕和私有地址〔PrivateDeviceAddress〕。Core_v4.2P2577的節(jié)描述了靜態(tài)地址。

圖5：靜態(tài)地址格式靜態(tài)地址有如下要求：

a)靜態(tài)地址的最高2位有效位必須是1。

b)

靜態(tài)地址最高2位有效位之外的其余局部不能全為0。

c)

靜態(tài)地址最高2位有效位之外的其余局部不能全為1。在私有地址的定義當中，又包含了兩個子類：不可解析私有地址〔Non-resolvablePrivateAddress〕和可解析私有地址(ResolvablePrivateAddress，RPA)。nRF51822使用的是靜態(tài)地址，芯片在出廠時已經(jīng)設置好了48位地址，我們可以從下面兩個存放器讀出地址類型和地址。

a)

DEVICEADDRTYPE存放器。DEVICEADDR[n]存放器：包含DEVICEADDR[0]和DEVICEADDR[1]兩個存放器。

圖6：地址類型存放器

圖7：地址存放器1.4

長度播送報文：長度域包含6個比特，有效值的范圍是6~37。

數(shù)據(jù)報文：長度域包含5個比特，有效值的范圍是0~31。播送報文和和數(shù)據(jù)報文的長度域有所不同，主要原因是：播送報文除了最多31個字節(jié)的數(shù)據(jù)之外，還必須要包含6個字節(jié)的播送設備地址。6+31=37，所以需要6比特的長度域。再次強調(diào)：播送時必須要包含6個字節(jié)的播送設備地址。1.5

數(shù)據(jù)(AdvData)播送和掃面響應的數(shù)據(jù)格式如以以以下圖所示，由有效數(shù)據(jù)局部和無效數(shù)據(jù)局部組成。

圖8：播送和掃描響應的數(shù)據(jù)格式1)

有效數(shù)據(jù)局部：包含N個ADStructure，每個ADStructure由Length，ADType和ADData組成。其中：Length：ADType和ADData的長度。ADType：指示ADData數(shù)據(jù)的含義。問題來了，我們?nèi)艉沃烙心男〢DType他們又表示什么意義可以通過下面2種方式查看ADType和他們表示的意義。從官網(wǎng)查詢，但是需要是會員才可以查詢。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對報頭、長度和數(shù)據(jù)進展計算。24位CRC的生成多項式如下：2.

播送包解析通過上文的描述，我們對BLE播送包有了大致的了解，接下來我們用EN-Dongle捕獲一個心率計的播送包，通過對實際播送包的分析來理解BLE報文構造和播送。播送包捕獲實驗的硬件連接如下。

圖9：硬件連接2.1心率計程序下載2.1.1

下載協(xié)議棧SoftDevice必須使用nRFgoStudio下載，翻開nRFgoStudio，切換到“ProgramSoftDevice〞選項卡。點擊“Browse…〞按鈕翻開SoftDevice的HEX文件〔位于“…\BLE實驗\藍牙協(xié)議棧(SoftDevice)目錄下的〞

s110〕。點擊“Program〞下載程序。2.1.1

下載應用程序應用程序可以用nRFgoStudio下載，也可以在MDK中直接下載調(diào)試，在這里我們用nRFgoStudio下載。切換到“ProgramApplication〞選項卡。點擊“Browse…〞按鈕翻開應用程序的HEX文件〔位于“…\BLE實驗\ble_app_beacon\pca10028\s110\arm5\_build〞目錄下的

nrf51822_xxaa_s110.hex〕。點擊“Program〞下載程序。2.2

捕獲播送包按照?藍牙4.0BLE抓包(一)?中的描述進展抓包，下面是我們捕獲一個心率計的播送包。

圖10：捕獲的心率計播送包

圖11：查看播送包傳輸?shù)臄?shù)據(jù)2.3分析播送包為了方便分析，我們先取出這個播送包實際傳輸?shù)臄?shù)據(jù)，如圖9中所示。心率計完整的播送報文如下：D6BE898E

40

2160BF8AB9CDC50B094E6F726469635F48524D

0319410302010607030D180F180A18

EFA6F02.3.1接入地址D6BE898E：接入地址，對播送來說是固定值。注意一下這里的字節(jié)序，接入地址傳輸時是低字節(jié)在前的。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個字節(jié)。

q

9A3F20FB74C5：設備地址，這里使用的是隨機靜態(tài)地址。接下來就是播送包最重要的局部了，稱之為AdvData，前面我們說過AdvData是N個ADStructure組層成，每個ADStructure的格式都是Length|ADType|ADData組成。0B094E6F726469635F48524D

0319410302010607030D180F180A18第一個字節(jié)0B表示第一個ADStructure的長度是11個字節(jié)，即第一個ADStructure是由0B加上緊跟著0B后面的11個字節(jié)組成，因此，第一個ADStructure是：0B094E6F726469635F48524D

表1：第1個ADStructure的意義LengthADTypeADData0B094E6F726469635F48524D11字節(jié)ADtype為“完整的本地名稱〞程序中定義的為〞Nordic_HRM〞對應的十六進制就是4E6F726469635F48524D第2個ADStructure是：03194103

表2：第2個ADStructure的意義LengthADTypeADData031941033字節(jié)ADtype為“外觀特性〞外觀特性是一個16位的數(shù)值，由SIG定義，用來列舉設備的外觀樣式，指示設備是普通手機，手環(huán)什么的。第3個ADStructure是：020106

表3：第3個ADStructure的意義LengthADTypeADData0201062字節(jié)ADtype為“Flag〞flag說明了物理連接功能，比方有限發(fā)現(xiàn)模式，不支持經(jīng)典藍牙等。l

bit0:LE

有限發(fā)現(xiàn)模式。l

bit1:LE

普通發(fā)現(xiàn)模式。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字節(jié)ADtype為“16bitServiceuuid列表〞該設備支持的完整的16bitServiceuuid列表。l

180D：HeartRateserviceUUID(心率服務UUID)l

180F：BatteryserviceUUID(電池服務UUID)l

180A：DeviceInformationserviceUUID(設備信息服務UUID)16bit

UUID：128位的UUID相當長，設備間為了識別數(shù)據(jù)的類型需要發(fā)送長達16字節(jié)的數(shù)據(jù)。為了提高傳輸效率，藍牙技術聯(lián)盟(SIG)定義了一個稱為“UUID基數(shù)〞的128位通用唯一識別碼，結合一個較短的16位數(shù)使用。二者仍然遵循通用唯一識別碼的分配規(guī)那么，只不過在設備間傳輸常用的UUID時，只發(fā)送較短的16位版本，接收方收到后補上藍牙UUID基數(shù)即可。藍牙UUID基數(shù)如下：00000000–0000–1000–8000–008059B34FB如要發(fā)送的16位UUID為0x2A01，完整的128的UUID便是：00002A01

–0000–1000–8000–008059B34FB低功耗藍牙使用的那局部UUID被分為以下幾組：l

0x1800~0x26FF：用作服務類通用唯一識別碼。l

0x2700~0x27FF：用于標識計量單位。l

0x2800~0x28FF：用于區(qū)分屬性類型。l

0x2900~0x29FF：用作特性描述。l

0x2A00~0x7FFF：用于區(qū)分特性類型。在程序的“ble_srv_common.h〞文件中定義了16bitservice

UUID，如下，當然也可以在SIG官網(wǎng)上查詢：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