廣播報文和掃描報文解析
關於廣播和掃描報文的解析如果想從協議本身就了解可以從頭看起，如果想直接看看芯片的開發怎么使用，可以直接從第2節，報文解析開始。
圖1 BLE報文結構
1.1 前導
前導是一個8比特的交替序列。根據接入地址的第一個比特為0或者1，分01010101和10101010兩種。接收機可以根據前導的無線信號強度來配置自動增益控制。
1.2 接入地址
接入地址有兩種類型：廣播接入地址和數據接入地址。
- 廣播接入地址：固定為0x8E89BED6，在廣播、掃描、發起連接時使用。
- 數據接入地址：隨機值，不同的連接有不同的值。在連接建立之后的兩個設備間使用。
1.3 報頭
1.3.1 廣播報文報頭
圖2 廣播報文報頭 圖3 Advertising channel PDU Header（core_v4.2 page 2583）
1)廣播報文類型
圖3 廣播報文類型
2) 發送地址類型和接收地址類型
發送地址類型和接收地址類型指示了設備使用公共地址(Public Address)還是隨機地址(Random Address)。公共地址和隨機地址的長度一樣，都包含6個字節共48位。BLE設備至少要擁有這兩種地址類型中的一種，當然也可以同時擁有這兩種地址類型。
- 公共地址(Public Address)
公共地址由兩部分組成，如下圖。公共地址由制造商從IEEE申請，由IEEE注冊機構為該制造商分配的機構唯一標識符OUI(Organizationally Unique Identifier)。這個地址是獨一無二，不能修改的。Core_v4.2 P2576的1.3.1節描述了公共地址。
圖4 公共地址結構
- 隨機地址
隨機地址有包含兩種：靜態地址（Static Device Address）和私有地址（PrivateDevice Address）。Core_v4.2 P2577的1.3.2.1節描述了靜態地址。
隨機地址有包含兩種：靜態地址（Static Device Address）和私有地址（PrivateDevice Address）。Core_v4.2 P2577的1.3.2.1節描述了靜態地址。
靜態地址有如下要求：
a) 靜態地址的最高2位有效位必須是1。
b) 靜態地址最高2位有效位之外的其余部分不能全為0和1。
在私有地址的定義當中，又包含了兩個子類：不可解析私有地址（Non-resolvable Private Address）和可解析私有地址(Resolvable Private Address，RPA)。CH57x使用的是靜態地址，芯片在出廠時自帶全球唯一的48位MAC地址。在提供的driver代碼中，有獲取MAC的接口，可以直接調用。
圖5 CH57x 獲取芯片MAC接口函數
1.4 長度
廣播報文：長度域包含6個比特，有效值的范圍是6~37。
數據報文：長度域包含5個比特，有效值的范圍是0~31。
廣播報文和和數據報文的長度域有所不同，主要原因是：廣播報文除了最多31個字節的數據之外，還必須要包含6個字節的廣播設備地址。6+31=37，所以需要6比特的長度域。
再次強調：廣播時必須要包含6個字節的廣播設備地址。
1.5 數據(AdvData)
廣播和掃面響應的數據格式如下圖所示，由有效數據部分和無效數據部分組成。
圖6廣播和掃描響應的數據格式
1) 有效數據部分：包含N個AD Structure，每個AD Structure由Length，AD Type和AD Data組成。其中：
Length：AD Type和AD Data的長度。
AD Type：指示AD Data數據的含義。
AD Type的意義可以通過下面2種方式查看AD Type和他們表示的意義。
從官網查詢，但是需要是會員才可以查詢。
https://www.bluetooth.org/Technical/AssignedNumbers/generic_access_profile.htm
查看WCH的SDK中的定義，AD type的定義在程序的“CH57xBLE_LIB.h”頭文件中。定義如下：
// GAP_ADTYPE_DEFINES GAP Advertisement Data Types
#define GAP_ADTYPE_FLAGS 0x01 //!< Discovery Mode: @ref GAP_ADTYPE_FLAGS_MODES
#define GAP_ADTYPE_16BIT_MORE 0x02 //!< Service: More 16-bit UUIDs available
#define GAP_ADTYPE_16BIT_COMPLETE 0x03 //!< Service: Complete list of 16-bit UUIDs
#define GAP_ADTYPE_32BIT_MORE 0x04 //!< Service: More 32-bit UUIDs available
#define GAP_ADTYPE_32BIT_COMPLETE 0x05 //!< Service: Complete list of 32-bit UUIDs
#define GAP_ADTYPE_128BIT_MORE 0x06 //!< Service: More 128-bit UUIDs available
#define GAP_ADTYPE_128BIT_COMPLETE 0x07 //!< Service: Complete list of 128-bit UUIDs
#define GAP_ADTYPE_LOCAL_NAME_SHORT 0x08 //!< Shortened local name
#define GAP_ADTYPE_LOCAL_NAME_COMPLETE 0x09 //!< Complete local name
#define GAP_ADTYPE_POWER_LEVEL 0x0A //!< TX Power Level: 0xXX: -127 to +127 dBm
#define GAP_ADTYPE_OOB_CLASS_OF_DEVICE 0x0D //!< Simple Pairing OOB Tag: Class of device (3 octets)
#define GAP_ADTYPE_OOB_SIMPLE_PAIRING_HASHC 0x0E //!< Simple Pairing OOB Tag: Simple Pairing Hash C (16 octets)
#define GAP_ADTYPE_OOB_SIMPLE_PAIRING_RANDR 0x0F //!< Simple Pairing OOB Tag: Simple Pairing Randomizer R (16 octets)
#define GAP_ADTYPE_SM_TK 0x10 //!< Security Manager TK Value
#define GAP_ADTYPE_SM_OOB_FLAG 0x11 //!< Security Manager OOB Flags
#define GAP_ADTYPE_SLAVE_CONN_INTERVAL_RANGE 0x12 //!< Min and Max values of the connection interval (2 octets Min, 2 octets Max) (0xFFFF indicates no conn interval min or max)
#define GAP_ADTYPE_SIGNED_DATA 0x13 //!< Signed Data field
#define GAP_ADTYPE_SERVICES_LIST_16BIT 0x14 //!< Service Solicitation: list of 16-bit Service UUIDs
#define GAP_ADTYPE_SERVICES_LIST_128BIT 0x15 //!< Service Solicitation: list of 128-bit Service UUIDs
#define GAP_ADTYPE_SERVICE_DATA 0x16 //!< Service Data - 16-bit UUID
#define GAP_ADTYPE_PUBLIC_TARGET_ADDR 0x17 //!< Public Target Address
#define GAP_ADTYPE_RANDOM_TARGET_ADDR 0x18 //!< Random Target Address
#define GAP_ADTYPE_APPEARANCE 0x19 //!< Appearance
#define GAP_ADTYPE_ADV_INTERVAL 0x1A //!< Advertising Interval
#define GAP_ADTYPE_LE_BD_ADDR 0x1B //!< LE Bluetooth Device Address
#define GAP_ADTYPE_LE_ROLE 0x1C //!< LE Role
#define GAP_ADTYPE_SIMPLE_PAIRING_HASHC_256 0x1D //!< Simple Pairing Hash C-256
#define GAP_ADTYPE_SIMPLE_PAIRING_RANDR_256 0x1E //!< Simple Pairing Randomizer R-256
#define GAP_ADTYPE_SERVICE_DATA_32BIT 0x20 //!< Service Data - 32-bit UUID
#define GAP_ADTYPE_SERVICE_DATA_128BIT 0x21 //!< Service Data - 128-bit UUID
#define GAP_ADTYPE_3D_INFO_DATA 0x3D //!< 3D Information Data
#define GAP_ADTYPE_MANUFACTURER_SPECIFIC 0xFF //!< Manufacturer Specific Data: first 2 octets contain the Company Identifier Code followed by the additional manufacturer specific data
// GAP_ADTYPE_FLAGS_MODES GAP ADTYPE Flags Discovery Modes
#define GAP_ADTYPE_FLAGS_LIMITED 0x01 //!< Discovery Mode: LE Limited Discoverable Mode
#define GAP_ADTYPE_FLAGS_GENERAL 0x02 //!< Discovery Mode: LE General Discoverable Mode
#define GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED 0x04 //!< Discovery Mode: BR/EDR Not Supported
圖7 廣播類型定義
1.6 校驗
BLE采用的是24位CRC校驗。CRC對報頭、長度和數據進行計算。24位CRC的生成多項式如下：
2. 廣播包解析
通過上文的描述，我們對BLE廣播包有了大致的了解，接下來我們用沁恆的BLE Analyzer捕獲一個peripheral的廣播包，通過對實際廣播包的分析來理解BLE報文結構和廣播。廣播包捕獲實驗的硬件連接如下。
http://www.wch.cn/downloads/WCH_BLEAnalyzer_zip.html（包含安裝軟件和使用說明）
3. 實例解析
以EXAM\BLE\Peripheral為例，進行廣播和掃描報文的解釋
3.1 代碼部分
// GAP - SCAN RSP data (max size = 31 bytes)
static uint8 scanRspData[ ] =
{
// complete name
0x12, // length of this data AD Structure
GAP_ADTYPE_LOCAL_NAME_COMPLETE, len + GAP_ADTYPE + data
'S', 'i', 'm', 'p', 'l','e',' ','P','e','r','i','p','h','e','r','a','l',
// connection interval range
0x05, // length of this data
GAP_ADTYPE_SLAVE_CONN_INTERVAL_RANGE,
LO_UINT16( DEFAULT_DESIRED_MIN_CONN_INTERVAL ), // 100ms AD Structure
HI_UINT16( DEFAULT_DESIRED_MIN_CONN_INTERVAL ), len + GAP_ADTYPE + data
LO_UINT16( DEFAULT_DESIRED_MAX_CONN_INTERVAL ), // 1s
HI_UINT16( DEFAULT_DESIRED_MAX_CONN_INTERVAL ),
// Tx power level
0x02, // length of this data AD Structure GAP_ADTYPE_POWER_LEVEL, len + GAP_ADTYPE + data
0 // 0dBm
};
// GAP - Advertisement data (max size = 31 bytes, though this is best kept short to conserve power while advertising)
static uint8 advertData[] =
{
// Flags; this sets the device to use limited discoverable mode (advertises for 30 seconds at a time) instead of general discoverable mode (advertises indefinitely)
0x02, // length of this data AD Structure
GAP_ADTYPE_FLAGS,
DEFAULT_DISCOVERABLE_MODE | GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED,
// service UUID, to notify central devices what services are included in this peripheral
0x03, // length of this data
GAP_ADTYPE_16BIT_MORE, // some of the UUID's, but not all
LO_UINT16( SIMPLEPROFILE_SERV_UUID ), AD Structure
HI_UINT16( SIMPLEPROFILE_SERV_UUID )
};
准備好廣播和掃描報文數據，使用時需要將這些信息通過RF發出去，具體在代碼中實現方式如下，使用到的函數如下：
藍牙初始化函數如下：
BLE分析儀抓包
從上圖可以看到：
第一行廣播包，間隔時間約(Time：+54394us)50ms
廣播包數據
看看PDU（Packet data）報頭*1B+長度*1B+MAC*6B+數據
數據部分與advertData定義相同，如果需要添加數據部分，需要按照AD Structure的構造去添加。
后面2行是主機向地址0x84C2E4030252發起掃描請求（SCAN_REQ），然后設備對於掃描請求的響應(SCAN_RSP).
響應數據如下：
看看PDU（Packet data）報頭*1B+長度*1B +MAC*6B+數據。
數據部分與scanRspData相同，如果修改需要按照AD Structure的構造去改造，並且保證長度不超過31B。
其他的AD Structure不過多的講，着重說一下UUID：
UUID定義：
“GATT層”中定義的所有屬性都有一個UUID值，UUID是全球唯一的128位的號碼，它用來識別不同的特性。
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：用於區分特性類型。