RFCOMM（一）

本文主要是介绍RFCOMM（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、概述

1、RFCOMM协议就是在L2CAP上进行串口（RS-232 9针）仿真，这个协议以GSM 07.10为基础，但是只使用了其中的一部分。此外，还增加了一个RFCOMM特定的延伸：基于credit的流控方案

2、RFCOMM协议最大支持在两个蓝牙设备之间建立60个连接

3、RFCOMM使用的是小端序，即先发送低位，再发送高位

4、两个设备之间的多个RFCOMM连接用Data Link Connection Identifier (DLCI)区分；

5、多个设备之间的多个RFCOMM连接，多个设备之间用L2CAP的CID区分，一个设备的多个RFCOMM连接之间用DLCI区分；

6、DLCI是一个6bit的值，可用范围2-61，DLCI 0是control channel专用，DLCI 1不可用，DLCI 62和63保留

7、RFCOMM支持的GSM 07.10的frame types有5种：

Set Asynchronous Balanced Mode (SABM) command：使用这个命令可以使目标设备进入异步平衡状态（ABM），这个状态下control字段都是一个byte的长度。目标设备收到这个命令后，应该尽快使用UA response（Unnumbered Acknowledgement (UA) response）确认接受，并重置DLC的发送和接收状态变量。

Unnumbered Acknowledgement (UA) response：这个response用来告知收到和接受SABM命令和DISC命令。

Disconnected Mode (DM) response：这个response用来通知本地状态是断开状态。如果在断开状态下收到DISC命令，则需要回复DM response。

Disconnect (DISC) command：这个命令用来断开一个DLC，进入断开模式。但是在执行这个命令前需要收到接收端回复的UA response（即发送DISC还不能算断开，需要收到UA才算断开）

Unnumbered information with header check (UIH) command and response：用来发送普通数据的，UIH帧的FCS只需要计算address、control和length字段。

8、RFCOMM支持的GSM 07.10的message type：

Test Command (Test)

Flow Control On Command (Fcon)

Flow Control Off Command (Fcoff)

Modem Status Command (MSC)

Remote Port Negotiation Command (RPN)

Remote Line Status (RLS)

DLC parameter negotiation (PN)

Non Supported Command Response (NSC)：当收到一个不支持command时，可以使用这个回复

二、详细介绍

1、RFCOMM frame格式

GSM 07.10规定的basic option frame的格式如下图所示：

但是RFCOMM frame跟GSM 07.10规定的basic option frame的格式有所不同，需要去掉opening flag和closing flags，即上图中开头和结尾的两个flag。

一个L2CAP frame只能放一个RFCOMM frame

（1）Address字段

RFCOMM和GSM07.10关于Address的格式是不同的，如下图所示：

①EA字段：这个字段是1

②C/R字段：

对于UIH帧，initiator发送给responder，C/R为1，response发送给initiator C/R为0；

对于SABM、UA、DM和DISC帧，C/R的设置根据下图所示：

这个表的描述挺晕的，简单说就是：

Initiator发起的command，C/R设置为1，Responder对这个command的response，C/R也设置为1；

Responder发起的command，C/R设置为0，Initiator对这个command的response，C/R也设置为0；

注意：Initiator就是发起连接的设备，即在DLCI 0上发送SABM command的设备，Responder就是接受连接的设备，即在DLCI 0上发送UA response的设备

Responder

③D字段：即direction bit，对于一个RFCOMM session，Initiator的D=1，Responder的D=0，在这个RFCOMM session上建立的连接，如果是Initiator发起的（方向是发往Responder），则这个连接交互RFCOMM packet的D=0（DCLI=0+ server channel<<1），如果是Responder发起的（方向是发往Initiator），则这个连接交互RFCOMM packet的D=1（DCLI=1+ server channel<<1）

④Server Channel字段：这个就是上层profile用到的RFCOMM channel，这个RFCOMM channel是在SDP中注册的，问询SDP时，可以获取到这个RFCOMM channel

（2）Control字段

如下图所示：

①如果是SABM、UA、DM、DISC，规则如下：

其中，P/F是Poll/Final位，在Commands中，被称为P位；而在Responses中则被称为F位，当发送的Command需要一个response时，就将P置1，接收方收到这样的命令时需要马上响应并将F置1

在一个DLCI上，发出一个P=1的frame在没有收到回复前不能发送下一个P=1的frame。

如果接收到P/F位置为0的SABM或DISC帧，接收方将把它们丢弃，如果收到一个未请求的DM帧，则不考虑P/F的设置。

一般来说可以在任何时候发送F=0的响应帧，但是如果收到一个F=0的UA frame，则应该丢弃

②如果是UIH，规则如下：

P/F设置为0（Credit Based Flow Control除外）

（3）Length Indicator：表示Information字段的长度，格式如下图所示：

Length Indicator可能是一个字节也可能是两个字节，具体根据第一个字节的E/A bit决定，当E/A=1时，表示只有一个字节，当E/A为0时，表示有2个字节。

（4）Information字段：存放具体的负载数据。注意：在RFCOMM中，只有UIH有这个字段

（5）FCS字段：

不同frame type,其FCS的计算方法也不同，计算方法如下：

对于SABM, DISC, UA, DM这四种frame计算：Address、Control和Length字段；

对于UIH frame计算：Address和Control字段；

三、frame type

Frame type由RFCOMM frame的control字段决定

1、Set Asynchronous Balanced Mode (SABM) command如下图所示：

SABM control字段的定义：

2、Unnumbered Acknowledgement (UA) response如下图所示：

UA control字段的定义：

3、Disconnected Mode (DM) response如下图所示：

DM control字段的定义：

4、Disconnect (DISC) command如下图所示：

DISC control字段的定义：

UIH control字段的定义：

6、举例

（1）SABM、UA、DM、DISC帧格式：

以DM帧为例：

①address字段是0x9b，即1001 1011：

bit 1是EA固定是1

bit 2是C/R，因为是master是Initiator，master发起的command，而这个DM response是slave回复command的，所以C/R=1

bit 3是D，如下图可以看到channel0x19是master发起的，而master是Initiator，所以D=0

bit 4-8是server channel，即0x11001=0x19

②control字段是0x1f，即00011111，DM control字段的定义如下，master发送DISC时，设置的P位为1，所以这里F为也设置为1

③length字段：0x01，即0000 0001

Bit 1是EA，因为只有length字段只有一个字节，所以设置EA=1

Bit 2-7：长度为0x0

④FCS字段：即0x2F

（2）UIH帧格式：

①address字段是0x9b，即1001 1011：

bit 1是EA固定是1

bit 2是C/R，因为是master是Initiator，所以master发送的UIH的C/R=1

bit 3是D，如下图可以看到channel0x19是master发起的，而master是Initiator，所以D=0

bit 4-8是server channel，即0x11001=0x19

②control字段是0xef，即11101111，UIH control字段的定义如下

③length字段：0x11，即0001 0001

Bit 1是EA，因为只有length字段只有一个字节，所以设置EA=1

Bit 2-7：长度为000 1000=8，注意看length字段的定义，如果是1010 0101，则长度是101 0010

④information字段：83 00 08 cb 00 00 00 01

⑤FCS字段：即0x27

四、message type

1、DLC parameter negotiation (PN)

这个message用来确定DLC的参数，在RFCOMM中，这个message是必须的，DLC建立之前要使用这个message。在PN message里面，Initiator要启动credit based flow control。DLC建立以后也可以使用这个message，但是不一定有效果。

主要设置：是否支持credit based flow control、DLCI、max frame size、初始credit数量

格式：

（1）message type格式如下图所示：

①EA：固定是1

②C/R：用来区分是command还是response，如果是command，则C/R=1（message type=0x83），如果是response，则C/R=0（message type=0x81）；

（2）message length字段：和RFCOMM frame里面的length字段一样，因为这个length是8，所以E/A=1

（3）message data字段：这里面的数据就是具体的Parameter，格式如下图所示：

D-bits：表示的是DLCI。D1是direction bit，D2-D6是server channel

I-bits：设置为0000

CL-bit：设置如下：蓝牙v1.0B以前，PN request和response中都设置为0000，但是蓝牙v1.1以后，PN request设置为0xF（表示credit based flow control），PN response回复0xE（表示支持credit based flow control，其他值表示不支持）。注意：如果在已经建立的DLC上使用PN request，CL-bit要设置成0x0

P-bit：表示分配给DLC的优先级priority，取值0-63,0表示最低优先级，RFCOMM中设置为0即可

T-bit：设置为0000 0000

N-bit：表示max frame size。收到PN request后，使用PN response回复时，要求N1r（PN response中包含的） <= N1c（PN request中包含的）；注意：整个N-bit称为N1，并不是说N1 bit。默认值是127，如果DLC连接前没有PN message交互，则使用默认值

NA-bit：设置为 0000 0000

K-bit：在RFCOMM中表示初始credit数量。可以在0-7之间任意取值，在蓝牙V1.0B以前，这个字段设置为0x0。注意：如果不支持credit based flow control，这个字段也应该设置为0x0

注意：收到PN request，可以回复PN response或者DM command，当PN request中的参数无效时，可以回复PN response（里面包含自己可以接受参数值）或者回复DM command

举例：