蓝牙学习笔记之RFCOMM协议（三）

目录

RFCOMM协议概览

协议浅述

服务概述

RS-232控制信号

无调制解调器仿真

多串口仿真

RFCOMM帧类型

RFCOMM帧格式

 Address字段

Control字段

Length字段

Data字段

FCS字段

RFCCOMM协议数据分析

---

RFCOMM协议概览

协议浅述

RFCOMM协议基于L2CAP协议的串行(9针RS-232)仿真。最新规范是V12，支持在两个蓝牙设备间高达60路的通信连接。该协议基于ETSI标准GSM 07.10（该文档在我（序篇）的网盘中可以找到），但不包含全部规范相反，只使用了GSM 07.10标准的一个子集。本文档中指定了该协议的一些修改，此外，还增加了RFCOMM特定的扩展，使其能够强制支持流控。

RFCOMM的目的是覆盖使用其所在设备的串行端口的应用程序，该规范支持两种设备类型的存在：

Type 1: DTE, 设备本身就是通信终端(如计算机，打印机) 

在简单的配置下，通信段是一个从一个设备到另一个设备的蓝牙链接，如下图：

Type 2: DCE, 通信节点(调制解调器)

当作为通讯节点使，其中通信段是另一个网络，蓝牙无线技术用于设备和网络连接设备(如调制解调器)之间的路径。RFCOMM只关心直接连接情况下设备之间的连接，或者网络情况下设备与调制解调器之间的连接。RFCOMM可以支持其他配置，比如在一端通过蓝牙无线技术通信的模块，在另一端提供有线接口。但是设备并不是真正的调制解调器，而是提供类似的服务。如下图所示：

服务概述

如果通过RFCOMM服务接口为特定端口设置波特率，则不会影响RFCOMM中的实际数据吞吐量;即RFCOMM不会导致人为的速率限制或节奏。但是，如果其中一个设备是类型2的设备(将数据中继到其他媒体)，或者如果数据踱步在RFCOMM服务接口的任何一端或两端进行，实际吞吐量平均将反映波特率设置

RS-232控制信号

RFCOMM模拟了9针RS-232接口，如下所示

无调制解调器仿真

当传递非数据通路的状态信息时，不区分DTE和DCE设备， 而用控制信号来代替相应的信号，对应关系如下图：

GSM 07.10传输RS-232控制信号的方式创建了一个隐式零调制解调器，当两个同类设备(如DTE)互联时，GSM 07.10传输控制信号时就会创建零调制解调器。下图显示了通过RFCOMM连接两个DTE时创建的Null Modem ：

多串口仿真

• 两个设备间的多串口仿真

两个使用RFCOMM通信的蓝牙设备可以同时打开多个串口仿真 ，RFCOMM支持最多60路，但是一个设备实际能打开的数据依实现而定，具体情况如下图所示：

一个数据链接标识(DLCI: 参考帧格式Address字段D+ServerChannel)标识一对客户和服务器之间的持续连接 。DLCI在两个设备间的RFCOMM会话中保持一致，中其可用值区间为2~61，0为控制信道 ，1由于服务器信道概念不能使用 ， 62-63保留。具体请参《3GPP TS 07.10 V7.2.0》第5.6节。

在一次RFCOMM会话中，客户和服务器可以分布在通信的两端，每一端的客户都可以独立发起建立通信连接 
因此可使用RFCOMM服务器信道的概念将DLCI值域空间在两个正在进行通信的设备间进行划分

• 多仿真串口和多蓝牙设备(Optional)

如果蓝牙设备支持多串口仿真，同时通信连接两端允许使用不同BT设备 
那么RFCOMM实体必须能够运行多路复用会话，每个多路复用使用L2CAP信道标识符(CID)来区分，如下图所示

RFCOMM帧类型

RFCOMM支持的帧(Frame)类型如下：

 

GSM 07.10 帧类型还有UI不能被RFCOMM所支持，对每个帧具体的意义请参考《3GPP TS 07.10 V7.2.0》5.3节或《3GPP TS 07.10 中文版》第3.3节。

RFCOMM帧格式

RFCOMM帧格式如下所示 

 Address字段

Address字段如下图所示，在GSM07.10和RFCOMM中有所区别：

EA(Extern Address)字段: 当为1时，表示没有额外的地址段。
C/R(Command/Response)字段: 表示该帧是一个Command还是Response,设置方式如下图所示 ：

DCLI（或direction bit and server channel）, 通常initator将D位(即最低位)设置为1，而Responser则将其设置为0 ，故initator的DCLI的值总是基数(3,5,7,…,61)，而Responser则为偶数(2,4,6,…,60)

Control字段

Control字段用来标识帧的类型，下图是相关值 

其中，P/F是Poll/Final位，在Commands中，被称为P位；而在Responses中则被称为F位 。当发送的Command需要一个相应时，就将P置1，接收方收到这样的命令时需要马上响应并将F置1 。如果接收到P/F位置为0的SABM或DISC帧，接收方将把它们丢弃 

Length字段

Length字段由最低位的EA来决定其长度 
当EA为1时，长度为7bits(0~127) 
当EA为0时，长度为15bits(0~32767)

其中，RFCOMM帧的默认长度为127，最大长度为32767

Data字段

Data字段仅仅在UIH帧中存在，其长度限制由L2CAP的MTU所限制

FCS字段

用于接收方校验接收数据是否正确，校验原理采用循环冗余校验CRC-8

对于SABM,DISC,UA和DM帧，FCS计算Address,Control and Length字段 
对于UIH帧，FCS计算Address and Control字段

RFCCOMM协议数据分析

下面我们将对RFCOMM完整的一次建立过程进行数据分析。

以下蓝色为hci部分、绿色为l2cap部分、红色为RFCOMM部分，这里我只针对RFCOMM协议进行解析，如果你对其他协议有兴趣，可以去看我的其他协议的数据分析

1、Master：SABM(Frame Type)

00000010 00000010 00100000 00001000 00000000 00000100 00000000 11000000 00000000 00000011 00111111 00000001 00011100

Address：000000 1 1（此字段可以分为三部分，根据下图所描述，有两种结构，一种是GSM 07.10结构，一种为蓝牙RFCOMM结构）

{

DLCI：00000 0

{

D：0（当为RFCOMM时为1，其他都为零）

Server Channel：00000（0x00，服务通道为0）

}

Command/Response（C/R）：1（Initiator Started C/R Sequence）

Extension Bit(EA)：1（Not Extended）

}

Frame Type：00111111（根据下表可知为SABM(Set Async Balanced Mode)）

{

Poll/Final Bit（P/F）: 1（bit-4位，当建立Data Link Connection(DLC)时，一般是由TE(Terminal Equipment )发起发送一个SABM，并将该位（Poll）置一，MS(Mobile Station) 确认连接时回复的UA(Unnumbered Acknowledgement)包的该位（Final）也应该被置一）

}

Length：0000000（0x00，数据长度为0）

Extension Bit(EA)：1（没有额外的字节描述数据长度）

FCS：00011100（0x1c，冗余校验）

2、Slave：UA

00000010 00000010 00100000 00001000 00000000 00000100 00000000 01000011 00000000 00000011 01110011 00000001 11010111

Address：00000011（此字段可以分为三部分，解析如下）

{

DLCI：00000 0

{

D：0（当为RFCOMM时为1，其他都为零）

Server Channel：00000（0x00，服务通道为0）

}

Command/Response（C/R）：1（Initiator Started C/R Sequence）

Extension Bit(EA)：1（Not Extended）

}

Length：0000000（0x00，数据长度为0）

Extension Bit(EA)：1（没有额外的字节描述数据长度）

FCS：11010111（0xd7，冗余校验）

3、Master：UIH

00000010 00000010 00100000 00010010 00000000 00001110 00000000 11000000 00000000 00000011 11101111 00010101 10000011 00010001 00000010 11110000 00000000 00000000 00000000 00000001 00000000 00000111 01110000

Address：000000 1 1（此字段可以分为三部分）

{

DLCI：00000 0

{

D：0（当为RFCOMM时为1，其他都为零）

Server Channel：00000（0x00，服务通道为0）

}

Command/Response（C/R）：1（Initiator Started C/R Sequence）

Extension Bit(EA)：1（Not Extended）

}

Frame Type：11101111（查表可知为UIH(Unnumbered Info with Header Check)）

{

Poll/Final Bit（P/F）: 0（bit-4位）

}

Length：0001010（0x0a，数据长度为10）

Extension Bit(EA)：1（没有额外的字节描述数据长度）

UIH Command/Response：（多路控制通道消息的格式如下：）

Type的格式如下图所示：

当EA为1时表示这是最后一个字节，当为0时则表示有扩展的字节表述，如下图：

T位代表类型编码，编码与命令的对应关系如下图所示：

Type：10000011

Command：100000（0x20，查表可知为PN命令）

Command/Response(C/R)：1（Command）

Extension Bit(EA): 1（Not Extended）

Length字段格式如下：

当EA为1时表示这是最后一个字节，当为0时则表示有扩展的字节

Length：00010001

Length：0001000（0x08，value的长度为8）

Extension Bit(EA): 1（Not Extended）

Value根据不同的命令有不同的描述，在《3GGP TS 07.10 中文版》第3.4.6.3节有详细介绍，则此处为PN的值的描述，如下图：

具体参数介绍，请参考《3GGP TS 07.10 中文版》第3.4.6.3.1节

Value：

DLCI(D)：000010（0x02，协商数据传输的DLCI）

Credit Based Flow Control(CL)：1111（0x0f，Sender Supports CFC）

Type of Frame for Information(I)：0000（0x0，UIH Frames）

Priority(P)：000000（0x0，优先级为0，0为最低优先级）

Acknowledgement Timer(T)：0（0x0，等待确认时间为0）

Maximum Frame Size(N)：00000000 00000001（0x0100，最大帧大小为256）

Maximum Number of Retransmission(NA)：00000000（0x0，最大重发次数为0）

Credits(K)：111（0x07，窗口大小，即帧数量的的最大值，此处设置为7）

FCS：01110000（0x70，冗余校验）

UIH Command/Response：

Type：10000011

Command：100000（0x20，查表可知为PN命令）

Command/Response(C/R)：1（Command）

Extension Bit(EA): 1（Not Extended）

Length：00010001

Length：0001000（0x08，value的长度为8）

Extension Bit(EA): 1（Not Extended）

 

篇幅原因，上面我只举了前两个协议交互例子进行分析，后续的协议的log以及数据分析，以及相关资料，请到我的博客<蓝牙学习笔记（序）>最下面的网盘链接中下载！​​​​​​​