蓝牙学习笔记之RFCOMM协议(三)

目录

RFCOMM协议概览

协议浅述

服务概述

RS-232控制信号

无调制解调器仿真

多串口仿真

RFCOMM帧类型

RFCOMM帧格式

 Address字段

Control字段

Length字段

Data字段

FCS字段

RFCCOMM协议数据分析


RFCOMM协议概览

协议浅述

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

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

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

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

蓝牙学习笔记之RFCOMM协议(三)_第1张图片

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

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

服务概述

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

RS-232控制信号

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

蓝牙学习笔记之RFCOMM协议(三)_第2张图片

无调制解调器仿真

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

蓝牙学习笔记之RFCOMM协议(三)_第3张图片

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

蓝牙学习笔记之RFCOMM协议(三)_第4张图片

多串口仿真

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

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

蓝牙学习笔记之RFCOMM协议(三)_第5张图片

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

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

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

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

蓝牙学习笔记之RFCOMM协议(三)_第6张图片

RFCOMM帧类型

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

蓝牙学习笔记之RFCOMM协议(三)_第7张图片

 

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

RFCOMM帧格式

RFCOMM帧格式如下所示 

蓝牙学习笔记之RFCOMM协议(三)_第8张图片

 Address字段

Address字段如下图所示,在GSM07.10RFCOMM中有所区别:

蓝牙学习笔记之RFCOMM协议(三)_第9张图片


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


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

Control字段

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

蓝牙学习笔记之RFCOMM协议(三)_第10张图片


其中,P/FPoll/Final位,在Commands中,被称为P位;而在Responses中则被称为F 。当发送的Command需要一个相应时,就将P1,接收方收到这样的命令时需要马上响应并将F1 如果接收到P/F位置为0SABMDISC帧,接收方将把它们丢弃 

Length字段


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

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

Data字段

Data字段仅仅在UIH帧中存在,其长度限制由L2CAPMTU所限制

FCS字段

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

对于SABM,DISC,UADM帧,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结构)

蓝牙学习笔记之RFCOMM协议(三)_第11张图片

{

DLCI:00000 0

{

D:0(当为RFCOMM时为1,其他都为零)

Server Channel:000000x00,服务通道为0

}

Command/Response(C/R):1Initiator Started C/R Sequence

Extension Bit(EA):1Not Extended

}

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

{

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

}

蓝牙学习笔记之RFCOMM协议(三)_第12张图片

Length:00000000x00,数据长度为0

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

FCS:000111000x1c,冗余校验)

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:000000x00,服务通道为0

}

Command/Response(C/R):1Initiator Started C/R Sequence

Extension Bit(EA):1Not Extended

}

Length:00000000x00,数据长度为0

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

FCS:110101110xd7,冗余校验)

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:000000x00,服务通道为0

}

Command/Response(C/R):1Initiator Started C/R Sequence

Extension Bit(EA):1Not Extended

}

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

{

Poll/Final Bit(P/F): 0bit-4位)

}

Length:00010100x0a,数据长度为10

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

UIH Command/Response:(多路控制通道消息的格式如下:)

Type的格式如下图所示:

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

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

蓝牙学习笔记之RFCOMM协议(三)_第13张图片

Type:10000011

Command:1000000x20,查表可知为PN命令)

Command/Response(C/R):1Command

Extension Bit(EA): 1Not Extended

Length字段格式如下:

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

Length:00010001

Length:00010000x08value的长度为8

Extension Bit(EA): 1Not Extended

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

蓝牙学习笔记之RFCOMM协议(三)_第14张图片

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

Value:

DLCI(D):0000100x02,协商数据传输的DLCI

Credit Based Flow Control(CL):11110x0fSender Supports CFC

Type of Frame for Information(I):00000x0UIH Frames

Priority(P):0000000x0,优先级为00为最低优先级)

Acknowledgement Timer(T):00x0,等待确认时间为0

Maximum Frame Size(N):00000000 000000010x0100,最大帧大小为256

Maximum Number of Retransmission(NA):000000000x0,最大重发次数为0

Credits(K):1110x07,窗口大小,即帧数量的的最大值,此处设置为7

FCS:011100000x70,冗余校验)

UIH Command/Response:

Type:10000011

Command:1000000x20,查表可知为PN命令)

Command/Response(C/R):1Command

Extension Bit(EA): 1Not Extended

Length:00010001

Length:00010000x08value的长度为8

Extension Bit(EA): 1Not Extended

 

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

你可能感兴趣的:(蓝牙协议栈)