Bluetooth技术学习笔记 —

参考：RFCOMM_SPEC_V12

DLCI：Data Link Connection，下行链路连接

1. RFCOMM帧

（1）帧类型：

Set Asynchronous Balanced Mode (SABM) command：异步平衡模式设置指令
Unnumbered Acknowledgement (UA) response：未加编号的确认响应
Disconnected Mode (DM) response：断开连接模式响应
Disconnect (DISC) command：断开连接指令
Unnumbered information with header check (UIH) command and response：携带头校验的未编号信息命令和响应

（2）帧结构：

Flag：L2CAP和RFCOMM之间交换的标志字段。

2. RFCOMM命令

在两个复用器之间，使用DLCI 0传输控制命令，RFCOMM支持的命令如下：

Test Command (Test)：测试命令
Flow Control On Command (Fcon)：打开流控命令
Flow Control Off Command (Fcoff)：关闭流控命令
Modem Status Command (MSC)：Modem状态命令
Remote Port Negotiation Command (RPN)：远程端口协桑命令
Remote Line Status (RLS)：远程连线状态
DLC parameter negotiation (PN)：DLC参数协商
Non Supported Command Response (NSC)：不支持命令类型响应。无论何时收到了不支持的命令，则发送NSC命令。

3. 复用器启动和关闭过程

任何时候，配对的设备之间最多存在一个RFCOMM会话。当建立一个新的DLC时，初始化建立的一方必须检查是否已经存在RFCOMM会话，如果已存在，则在此会话上建立新的DLC。一个会话由两个端点的蓝牙地址决定。

（1）启动过程：正在打开两个设备间的第一个仿真串口连接的设备负责建立多路复用控制信道，包括：

利用L2CAP服务原语，与对端RFCOMM实体建立L2CAP信道。
通过在DLCI 0上发送SABM命令启动RFCOMM多路复用器，并且等待对等实体的UA响应。

（2）关闭过程：正在关闭会话上最后一条DLC的设备负责关闭相关的L2CAP信道。在关闭L2CAP信道之前，设备可以在DLCI 0上发送DISC命令来关闭最后一个连接，其它的设备需要使用UA来响应DISC。

（3）链路丢失处理：若收到L2CAP链路丢失通知，则本地RFCOMM实体将向每个激活的DLC端口端口或代理实体发送连接丢失通知，并释放RFCOMM会话相关的所有资源。

4. 系统参数

Maximum Frame Size (N1)：最大帧长度
Acknowledgement Timer (T1)：用于P/F位设为1的帧超时（SABM、DISC）。通常T1的取值范围为10 ~ 60s。然而，为了启动一个新的DLC（DLC>0）而发送一个SABM，T1的取值范围为60 ~ 300s。
Response Timer for Multiplexer Control Channel (T2)：用于DLCI 0控制命令超时，命令在UIH帧中发送。

RFCOMM依赖于底层提供可靠的传输，若定时器超时，默认操作是关闭复用器会话。

5. DLCI分配

考虑到RFCOMM会话两端都可能存在客户端和服务器应用，以及各客户端独立地建立建立，将DLCI值域用RFCOMM服务信道和方向位进行划分。

D：进行初始化的设备设定为1，另一方设定为0。
给RFCOMM服务接口上注册的服务应用分配一个服务信道号，取值范围为1~30，服务信道号被寄存在服务发现数据库中。
DLCI由D和服务信道共同决定，初始化方的DLCI取值为3，5，7，…，61，非初始化方的DLCI取值为2，4，6…，60。

6. 复用器控制命令

在相应的DLC建立之前，一些与特定DLCI相关的多路复用器控制命令可以在DLCI 0上进行交换。

当收到断开连接（DISC）命令时，或本地端关闭DLC，DLC的相关状态重置为默认值。
若收到与未开放的DLCI相关的多路复用器控制命令，发送断开模式（DM）命令进行响应。
RFCOMM不允许在一个帧内包含多个复用器控制消息。

（1）RPN：远程端口协商命令

在新的DLC开放或任何端口设置改变前，使用该命令。
在RFCOMM中，该命令必须识别并响应。

（2）RLS：远程连线状态命令

该命令用于指示远程端口连线状态
在RFCOMM中，该命令必须识别并响应。

（3）PN：DLC参数协商命令

在RFCOMM会话上的第一个DLC建立前，至少使用一次DLC参数协商命令，且发起方需要尝试着开启流控。
DLC建立后，PN请求的响应端可以拒绝任何参数的改变，可在响应中携带当前参数。

7. 流控

（1）L2CAP流控：L2CAP流控依赖链路控制器启动和停止流控机制或基于每个L2CAP信道的流控机制。

（2）端口仿真实体流控

对于DTE设备，一些端口驱动器需要通过它们所仿真的API来定义流控服务。应用可以要求一些特殊的流控机制（如XON/XOFF，RTS/CTS），并希望由端口驱动器处理。
对于DCE设备，端口驱动器可能需要在非RFCOMM的通信路径上执行流控机制，即RS-232端口。
若RFCOMM有自己的流控机制，端口驱动器不需要执行应用层要求的流控机制。

端口驱动器流控仿真基本原则：

端口驱动器不会单独依赖于应用所请求的机制，可以结合使用不同的流控机制。
端口驱动器必须意识到应用所要求的流控机制，并且在硬件流控和软件流控上看起来像有线一样。
若应用通过端口驱动器接口设置了流控机制并调用了该机制，则端口驱动器的处理必须看起来和有线一样。

（3）基于Credit的流控

基于信用流控的使用需要服从之前的协商。

基于信用的流控基于单个DLC提供流控。RFCOMM会话的设备端都需要知道在DLC缓存溢出前，对端设备能接收多少帧。一个正在发送的实体可以发送与其DLC所含信用相等的帧数。如果信用为0，则发送者必须停止发送并等待可用的信用。

初始化DLC协商
DLC操作