EDA365电子论坛网
标题:
[经验] 蓝牙BLE 协议层 笔记
[打印本页]
作者:
sunygd
时间:
2016-5-30 16:37
标题:
[经验] 蓝牙BLE 协议层 笔记
' O& K q C. V/ y# Q
BLE协议：
) M. [7 i# N6 `% K, |% x
$ a# ~- l' E( }' O
PHY层：1Mbps自适应跳频GFSK（高斯频移键控），运行在免证的2.4GHz频段。
4 r/ x7 s; s% M' M1 |
! {$ o3 W( m3 D9 f+ _$ @
LL控制层：控制芯片工作在standby（准备）、advertising（广播）、scanning（监听扫描）、initiating（发起连接）、connected（已连接）这五个状态中的一种。发起连接的设备变为master（主机），接受连接请求的设备变为slave（从机）。
5 H) p, n7 H1 |# t+ R# `) a# ^- c) s! C
/ U+ l$ ]0 c# Z8 j
HCI层：为接口层，向上为主机提供软件应用程序接口（API），对外为外部硬件控制接口，可以通过串口、SPI、USB来实现设备控制。
6 j: g' a1 `+ S0 o0 V
4 w3 P3 @( K1 m
L2CAP层：为上层提供数据封装服务，允许逻辑上的端到端数据通信。·SM层：提供配对和密匙分发服务，实现安全连接和数据交换。·GAP层：直接与应用程序或配置文件（profiles）通信的接口，处理设备发现和连接相关服务。另外还处理安全特性的初始化。
* u: j8 R0 [# q* Q. ~: T( D
0 J3 r. q, W8 K4 Z6 @# I
ATT层：导出特定的数据（称为属性）到其他设备，允许设备向另外一个设备展示一块特定的数据，称之为"属性"，展示属性的设备称为server，预支配对的设备称为client。
! h2 n) f6 {9 b8 a- B
: I% u8 v& U5 Q% g+ i, V, H8 |$ ^
GATT层：定义了使用ATT的服务框架和配置文件（profiles）的结构。BLE中所有的数据通信都需要经过GATT。
! ? g( C- b6 t0 C: C* [' U
B$ Z) Z8 p; |1 K2 V9 M# h0 f
主设备可以连接多个从设备，一个从设备只能链接一个主设备。
6 T* I/ y# E7 K0 S
广播事件：可以包含特定数据，最大31字节，每次广播会在37/38/39通道分别发一次。
$ x- n+ W9 z$ }% r+ g" ?
广播间隔：20ms-10.24s，随机延迟：0-10ms为了避免碰撞
% q9 g7 h6 |: ]1 ]( D. q/ }! a
扫描事件：37/38/39通道交替
$ x' t, h' \. v- k) {' p( R
扫描间隔：每隔多少时间扫描一次
$ Y8 r6 q5 g5 W; Z( B
扫描窗口：每次扫描持续时间
6 V' m- A# C; r5 r. q
发起连接：发起方-主，广播方-从，报文可以包括一些连接参数。
8 V, }# ]- [6 F8 u: a
连接参数：
# V) s. f/ C, T) D7 c2 ~% V& ?- F
通道映射：指示连接使用的频道
4 s+ P, Q+ Q& D, Z0 B" O
调频增量：5-16之间，参与通道选择的算法
E: V4 J5 s3 G: K
连接间隔：1.25MS的倍数，7.5ms-4s之间
! E) k" K p& I8 o- S3 K
监督超时：10ms的倍数，100ms-32s之间
6 B9 U& Y6 k$ [% p
从机潜伏：0-499次数之间
/ b ~: O* F2 R$ F. [
连接事件：根据连接间隔，周期性地发生
% N& I- `' Q- a! Q8 U
主先发送，从在150us后响应。
' B' n$ T9 K1 a/ {
允许双方都没有数据发送（例外情况是从设备潜伏使能）
; m: ^* e2 u: @2 b9 t4 _
Slave潜伏：Slave如果没有数据发送，可以跳过连接事件。
1 ~& I( Y# X$ r8 n( A
Master会在后来的连接事件中重复发送，直到Slave响应。
7 \' |4 E: ^2 R! m, K" i+ E1 `
从设备的潜伏值最大499次，但必须小于32s。
9 h( @# U$ n9 O. T/ y
终止连接：主从都可发起断开连接，另一方必须回应请求。
1 b1 z9 e2 |0 f5 h J9 G8 x
监视超时而断开连接：时间必须小于32s。设备会退出连接状态，返回广播、扫描或待机模式。
, o( L7 n7 d; _' E4 e" A3 Y1 D/ u
3 _9 Q. i& c; N6 h
连接建立过程：
& ?3 N# ]9 G! g& b
Advertise：从机处于广播状态
8 c0 v( n! a- Y: j; s- _
主机 <-------------------------------------- 从机
/ t z6 u* e/ a# v' K
' F: O4 u" \( G* b) }! O
Scan Request：主机收到广播后发扫描请求
- `+ v; l9 z! h5 }( P
主机 --------------------------------------> 从机
: o6 ?3 ~7 i7 x
5 s2 T9 T. y7 f! A$ f0 L' T
Scan Response：从机收到请求后发扫描响应
' L+ D3 `, v7 c
主机 <-------------------------------------- 从机
) z7 s/ [" Z2 C
! \) g- b: D. R
Establish Link：主机发送连接请求
6 C+ Y0 [" Y* E$ T# o( w7 y
主机 --------------------------------------> 从机
. ]% i- G- S$ x8 |0 T& ?" \& X
- H+ r5 W) Q& @! l6 F
Pairing：配对过程，产生加密和认证密钥
: t* P. B2 V9 O
主机 <-------------------------------------> 从机
" l3 Q" @' ]) j; K
% F5 m6 @+ ^6 W: I& F+ r4 u
Bonding：绑定过程，下次连接可以快速配对
+ }* F, n7 [8 p- t4 \3 w2 v+ a
主机 --------------------------------------> 从机
2 x, s' j- N9 H+ z0 E
+ ^+ E+ Q, d) E" |9 u5 G* z+ J) ~! U
+ Q& g2 r8 Z- W7 D( i
4 a' [: N: o# v* {; e
------------------------------------------------------------
* B- ~& }$ ?, ^! K6 b7 G7 X
Profile
) E. M$ K& G4 U8 r# M p+ ^
6 T b( Q- Y Z5 ^4 _
profile 蓝牙配置文件，定义了可能的应用。可以把Profile理解为连接层或者应用层协议。
% l5 [$ _9 \* }7 e
3 Q6 |) r; j* U) g
四种最基本的配置文件：
- V- C5 [$ C0 i5 a4 h7 a
通用访问配置文件(Generic Access Profile, GAP)
, Q2 O2 ]* r4 t+ Y, ?9 x
GAP是所有其他配置文件的基础,它定义了在蓝牙设备间建立基带链路的通用方法。
; E4 O- Z3 G5 K1 C. H
GAP处理未连接的两个设备间的发现和建立连接过程。
$ k; d' x8 m \+ N" S2 X# @
服务发现应用配置文件(Service Discovery Application Profile, SDAP)
! Q, B" ~5 T/ _- C3 }, ~! v
SDAP描述了应用程序如何使用SDP发现远程设备上的服务。
7 V, g+ ~- y' I( b4 k
SDAP依赖于GAP,并可以重新使用部分GAP。
# [6 S1 [5 H: X6 R; b( ^% Z" p
串行端口配置文件(Serial Port Profile, SPP)
8 ~/ ~1 k7 S% t
SPP定义了如何设置虚拟串行端口及如何连接两个蓝牙设备。
. f5 ^4 R6 G" h+ @, {
使用RFCOMM协议提供串行商品仿真。
z, [% X7 X$ e/ b( x/ ~
SPP依赖于GAP。
3 K M- k F1 u/ x! w0 B) R
通用对象交换配置文件(Generic Object Exchange Profile, GOEP)
- k4 L: _0 j; a1 i( t: G; Y
GOEP可用于将对象从一个设备传输到另一个设备.对象可以是任意的.如:图片,文档,名片等。
1 t: A# ^- f9 r, e5 |7 J
此配置文件定义了两个角色:提供拉提或推送对象位置的服务器及启动操作的客户端。
. a2 A) ^% R8 ? S( X" D# B- Z
使用GOEP的应用程序假定链路和信道已按GAP的定义建立.GOEP依赖于串行端口配置文件。
$ i7 L$ E: I& l: k- r/ ~( J
GOEP为使用OBEX协议的其他配置文件提供了通用蓝图,并为设备定义了客户端和服务器角色。
9 Q6 z E; j+ k
它定义的是数据的传输，包括同步，文件传输，或者推送其它的数据。你可以把它理解为内容无关的传输层协议，可以被任何应用用来传输自己定义的数据对象。
2 X" h4 A( ~: f7 y& T& K, V: F( ^
蓝牙1.1版本规范所有蓝牙设备的最小实现必须支持通用访问配置文件,服务发现应用配置文件和串行端口配置文件。
' Q. t; i4 d0 h' B' q2 w
: L7 i1 O0 m3 K9 r; t' H! ^( g1 H
其他常见应用配置文件：
) t5 n; B6 E1 n$ X% ?- O" p
CTP Profile: Cordless Telephone Profile，无绳电话。
/ Z2 y' O/ d2 B- Q( h
IP Profile: Intercom Profile，这是在两个设备之间建立语音连接，换句话说，把两个昂贵的蓝牙设备变成廉价的对讲机。
. g/ M) t+ a, [& s
HS Profile: HeadSet Profile，用于连接耳机。
: P$ s' i! o, ^% ?) S! `
DNP Profile: Dial-up Networking Profile，用于为PC提供拨号网络功能。
2 [0 H0 o3 J; ^& y
FP Profile: Fax Profile，传真功能。
6 e2 s- w7 Y5 T% T( Y8 m6 e0 o% G
LAP Profile: LAN Access Profile，使用PPP协议建立局域网。
6 f* s, z% ` c8 L' x' ?
OPP Profile: Object Push Profile，用于设备之间传输数据对象。
" D1 F0 |; |. k2 _7 i
FTP Profile: File Transfer Profile，用于文件传输。
8 v! o8 @; G2 ~9 U
SP Profile: Synchronization Profile，用于不同的Bluetooth设备同步，保持数据的一致性。
9 n' N/ y* j7 S. ]1 ?! @) [. {
HID Profile: Human Interface Device Profile,人机接口设备.
2 j5 c# W) M: ^6 V/ R
) G7 j. ~; v- N+ B+ e* d- b) M
------------------------------------------------------------
3 q; T3 @6 x# b. u
Service,Attribute
8 q% r1 m4 F# b" i& \
8 j6 h- g; z. u6 R. q2 h1 A
ATT针对LE设备的优化：尽量短的字节数，基于固定长度的PDU实现
9 L0 R) P. E/ i
4 X: o+ p! {( Q0 c/ Q; a/ b
7 V. ~7 e; ?( _0 }3 }
属性协议（ATT）—GATT是建立在属性协议（ATT）的顶层，通常也被称为GATT/ATT。ATT进行了优化用于在BLE设备上运行。为此，它采用尽可能少的字节越好。每个attribute属性被UUID（通用唯一标识符）唯一标识，UUID是标准128-bit格式的ID用来唯一标识信息。attributes被ATT格式化characteristics和services形式进行传送。
1 ^# z9 p& A9 ?4 S3 j# ~
! W S. _8 {. x8 r" ]
特征（Characteristics）—一个characteristics包含一个单独的value值和0–n个用来描述characteristic值（value）的descriptors。一个characteristics可以被认为是一种类型的，类似于一个类。
2 r2 Z0 {& N0 x" M- k% q2 z
/ J9 O9 K) {; ^9 H+ I& ^9 q
描述符(descriptor)—descriptor是被定义的attributes，用来描述一个characteristic的值。例如，一个descriptor可以指定一个人类可读的描述中，在可接受的范围里characteristic值，或者是测量单位，用来明确characteristic的值。
$ S, j9 g/ y1 O: \0 N4 L, z7 d0 h& L
( ^! Z) F* _) c+ q
服务（service）—service是characteristic的集合。例如，你可以有一个所谓的―Heart RateMonitor service，其中包括characteristic，如―heart rate measurement 。
4 K$ M, n% W' d4 o1 J
1 O x5 p! a4 B& i* C# s. a1 _( i
0 D+ C) @" b2 B# L, N/ n
1 }: e/ z& ^$ S& \& \' v) B
Attribute属性，由3个元素组成：
# T: I" P# _6 K6 r0 o
handle：16bit，对属性唯一的ID，用来准确寻址。
9 ]/ I1 s0 a6 W; b( ^8 d
UUID：定义了属性的类型。
& y( i/ o* i z& L3 Y
Value：有固定长度。客户端根据自己对UUID类型的理解来知道确切的长度。
) G0 x) |, @/ u' u0 Q) m1 ^
属性权限：
/ i4 T4 I& @# A6 ]0 T
可读/不可读
" Z/ @! W0 O4 _0 _8 B( M6 s
可写/不可写
: @) q: D x D6 K% o. Q) B
可读和可写/不可读和不可写
* A& H, M# y n6 i. y! o! ~( P
读写属性的Value也许会要求：验证读写权限、授权、加密或配对。
+ c* r! J, Z" A/ F$ Y1 u) A# K: F0 D* u
2 C$ ^" e3 x# x% ^
属性的操作：读
- Z) G. ]' ^# R6 |+ h
客户端需要时请求数据。
9 t# \5 L9 J% x5 c
客户端轮询服务器上属性的value：当数据不经常改变时，效率低下，不建议采用。
3 [1 a8 V2 f/ F% w
属性的操作：写
. {/ j! I% r) n0 M/ y
客户端可以设置属性来配置服务器。例如设置房间温度为22度。
8 Q% A2 m' d+ q, X6 E
属性的操作：notify通知
+ C) p% I: ?7 `& ]$ K
客户端可以通过配置服务器来注册notify，服务器的数据改变时会notify客户端。
7 r7 g5 C1 \& A- m9 }. B
属性的操作：indicate指示
" d3 G5 Z, R5 k, O1 o( \3 ?* ~" M
服务器的数据改变时会indicate客户端，客户端确认收到数据。
% D2 S) A' f7 Z& c3 n8 x7 H3 ?
7 r! a7 g8 [+ ]
" n$ I4 V6 i! {+ i
每一个BLE Service都是基于GATT的。
[2 E/ X- i' c9 L! Y# Q6 O
+ U$ `9 p% {; f* n" w; w0 Y
ATT的服务器/客户端架构
/ d/ w( K6 F6 |( q+ a) M
服务器提供数据，客户端使用这些数据。
" `; S* \6 _* i
服务器通过操作属性的方式，提供数据访问服务。
2 j5 x& o% g2 O) r- \* Z
GATT Profile层次结构
2 n$ |/ J o! m9 [' Q# u
profile通常有一个或多个Services组成。
9 y- ^; O) ~. H1 f
一个Service或许包含多个characteristic特征。
* R, }7 H. y0 t
每个特征由一个结构来表示，包括属性Properties、值Value、描述符Descriptor
8 ^. M8 x5 l3 o# C6 p2 b
GATT客户端命令
; Z) S/ S/ J5 s; B+ N
Discover Characteristic by UIDD，搜索服务端设备所能提供的所有屁屁额UUID规范的属性。
' N2 @0 q4 g _+ e9 N8 }+ e
Read Characteristic Value，使用指定的handle读特征值。
3 Y& G$ S4 c6 B! n# b* [/ r
Write Characteristic Value，使用指定的handle写特征值。
* H/ a1 Q' o& s3 s4 h
Notification，某个特征值被发送到客户端，而没有被读请求，且不需要应答。
! h; m' x3 P# L' I) Q
Indication，某个特征值被发送到客户端，而没有被读请求，但在其他数据被发送前必须被确认。
l3 G+ S; s$ y" @0 `* t
/ W L: F/ u! c' f4 y1 H
0 O& Y# n4 O+ }5 }: Q& n6 X# h
SDP协议让客户机的应用程序发现存在的服务器应用程序提供的服务以及这些服务的属性。SDP只提供发现服务的机制，不提供使用这些服务的方法。每个蓝牙设备都需要一个SDP Service，只做Client的蓝牙设备除外。
# ^4 S' r* }$ D4 @% K6 J$ C3 a C
5 X* U: i$ y, F- e
Service Record：每一个Service利用ServiceRecord来表示（具有唯一的32bit的Handle)，每一个Service Record由若干Service Attribute组成。
- k1 l6 ?- ~: a2 T# n I9 E
. m. E0 W% z" c" b% V5 _1 l" E7 w; J
Service Attribute：每个ServiceAttribute 由Attribute ID（16bit）和Attribute Value组成。
; ^' t6 S7 f6 m6 i* q' T( s
可以把Record看成Atribute List。
9 n6 Z# E. h% O4 i; A
ServiceRecordHandle Attribute（ID= 0x0000，size=32bit）
$ C% W4 X8 {$ P! l Z. V8 c: X( l1 b; N
ServiceClassIDList Attribute（ID= 0x0001，数据元素序列）
3 i8 l+ E! T- w( x! t8 H1 G
ServiceRecordState Attribute（ID= 0x0002，size=32bit）
0 E# ~& w7 J% w* S* X
ServiceID Attribute （ID= 0x0003，即UUID）
9 B; K8 |1 \) W5 m2 h8 }) p
. }8 E8 t$ V# x" w: |9 b" N+ Q- \
Service Class：每一个Service都是ServiceClass的一个实例，一个Service Record就是一个Service Class的实例。
9 J! w" p4 v' l& h1 g. n" l
每一个Service Class有一个ID，包含在Service Class ID List这个Attribute的value里，称之为UUID。
" d/ P, Q" n+ {: }2 a
" z: x& F+ t( Z7 c' Q
UUID：一个全局惟一的标识符，128bit。为了节省存储和传输开销，UUID的一些位已经固定，出现了16bit和32bit的两种UUID。
作者:
Hh0203
时间:
2016-5-31 15:41
谢谢楼主！
作者:
marco5512
时间:
2020-7-16 07:54
好東西,謝謝分享,學習
欢迎光临 EDA365电子论坛网 (https://bbs.eda365.com/)
Powered by Discuz! X3.2