蓝牙attribute protocol



一条attribute包括type，handle，value以及permission。

Type用128bit的UUID定义。为了减少存储和传输消耗，对于一部分经常用的UUID，官方定义了一个规则，以16位或32位形式存储和传输，它们都是基于BluetoothBase UUID：

00000000-0000-1000-8000-00805F9B34FB。16位或32位UUID转化为128位的格式如下：

128_bit_value = 16_bit_value * 296+ Bluetooth_Base_UUID//存储和传输的是112位到97位

128_bit_value = 32_bit_value * 296+ Bluetooth_Base_UUID //存储和传输的是128位到97位

对于私有的UUID，存储和传输的是128位。

Handle：是访问attribute value的唯一方法，两个字节，最小值为0x0001,最大值为0Xffff,不能为0x0000。

Value：以字节为基本单位，有些attribute的长度是固定的，有些则是不固定的。

Permission:

Access permission: readable, writeable,readable and writeable.

Encryption permission: required or notrequired.

Authentication permission: required ornot required.：访问attribute的时候，如果required，那么需要建立一条authenticated link，无论是response还是notification和indication。

Authorization permission: required ornot required.

后面三种permission是access permission的辅助。

Control-point attribute：不能读，可以写或notify，indicate。这一类attribute基本是在给定的步骤完成之后用于激活一个功能。如高通的SPC值。

 

ATT_MTU，双方交换ATT_MTU。一条attribute的value如果比ATT_MTU长，这样的attribute称为long attribute，要读这样的long attribute，在读完第一条之后，需要使用read blob的方法获取剩余的attribute value。

 

ATT协议是sequential protocol，意思是如果client发送了request，那么必须等到收到response，才能发送下一条ATT request，但可以发command。如果server发送了indication，那么必须等到收到confirmation，server才能发送下一条indication，但可以发notification。一句话，request和response必须一一匹配，indication和confirmation必须一一匹配。一对request/response或indication/confirmation称为一个transaction。

 

ATT PDU：

Opcode：一个字节，bit7指示是否有authentication signature。Bit6指示该操作是否为command。Bit5-0位为method。

Attribute parameter：是method而定。

Authentication signature：如果bit7为1，则加12字节的签名，如果为0，则为0字节。Method按照method type分，有request，response，indication，confirmation，

command，notify。Request和response为一对，indication和confirmation为一对，command和notify单独使用，无需回复。

按功能分，则主要有：find，read，write，command，notification，indication和confirmation。

Find information:输入start和end handle，返回format指示attribute type的format是16bit还是128bit，再加上attribute handle和attribute type pair。注意，一条response中只有一种format。

Find by type value:通过type和value匹配来返回handles informationlist。通常用于group attribute。不怎么理解？？？Handle information的结构为found attribute handle和group end handle。

 

Read by type request：根据type匹配来读取handle-value pair.

Read request:根据handle来读取attribute value。

Read blob type:根据handle和offset来读剩余的attributevalue。

Read multiple request：根据handle组来读取attribute value。需要匹配到组里所有的handle且都允许被读，才能获取attribute value。每个handle对应的attribute长度必须为已知的固定值，这样才能解析返回的attribute value组。

Read by group type request:根据group type匹配来读取handle-group endhandle-attribute value组。

Write request：根据handle写attribute value。

Write command：根据handle写attribute value，不需要返回response。

Write signed command：根据handle写attribute value，request中带authenticationsignature。

Prepare write request：告诉server接收了之后暂存以便之后写入。Request包含handle，offset，value。Offset是指一条attribute中，部分写入的attribute的offset。需要response。可以多条Prepare write request，可以不同的handle。

Execute write request：通知server将之前接收到的prepare write request的attribute value进行写入操作。

Notification：server通知client，包含handle和value, client不需要回复server。如果是long attribute，那么需要client通过Read Blog将剩余的attribute value读回来。

Indication：server指示client，包含handle和value，需要client的confirmation回复。如果是long attribute，那么需要client通过Read Blog将剩余的attribute value读回来。

Confirmation：只需要Opcode就行了。