对于frame级来说，frame header中的C/R bit按照如下设置:

• 对于SABM,DISC,UA,DM frames C/R bit是根据GSM 07.10[1] 5.2.1.2节的表1来设置的。
• 对于UIH frames，C/R bit总是根据GSM 07.10[1] 5.4.3.1节来设置。这与UIH frame包含的内容(数据或控制message)无关。

对于Message级来说，命令类型字段中的C/R bit按照GSM 07.10 5.4.6.2节中描述的来设置。UIH frame中发送的Control message，frame header的address字段中的C/R bit总是按照 GSM 07.10 5.4.3.1节来设置，与control message是命令还是响应无关。

GSM 07.10 Mutiplexer的开启和关闭过程

不支持GSM 07.10 5.7节中明确的开启和关闭过程。这就意味着RFCOMM不支持AT命令AT+CMUX，也不支持Multiplexer关闭(CLD)命令。

任意时刻，任何一对设备之间最多只能存在一个RFCOMM会话。要建立新的DLC时，初始化实体需要检测和远端设备之间是否存在任意的RFCOMM会话，如果存在，只需要在该会话上建立新的DLC。会话由两个端点的Bluetooth BD_ADDR标识¹。

开启过程

在两个设备之间开启第一个模拟串行端口的设备需要负责建立第一个multiplexer control通道。它应:

• 使用L2CAP服务原语建立到对端RFCOMM实体的L2CAP通道，见L2CAP “Service Primitives”
• 在DLCI 0发送SABM命令，以此开启RFCOMM multiplexer，并且等待对端实体的UA response。(还可能会有更多的选择协商步骤)

这些步骤之后，为用户数据传输的DLCs就已经建立好了。

实现注意:如果两个RFCOMM实体尝试在已经存在的基带连接上同时建立会话，则会出现一种特殊情况。当RFCOMM实体在自身发出L2CAP连接请求之后收到了L2CAP连接指示时会出现这种情况。这种情况下，RFCOMM实体应对收到的连接指示做出负响应(因为两个RFCOMM实体之间只能由一个会话)。怎样处理这种情况需要根据实现来看(例如，可用在之后的一个随机时间点再试，或者推出，等待用户手动重试)。

¹ 这意味着，当响应L2CAP连接指示时，RFCOMM实体应保存新的RFCOMM会话并将其与远端BD_ADDR关联起来。这是有必要的，如果后续的DLC建立来自反方向的话(依据设备的能力)，上述做法是有必要的。

关闭过程

关闭特定会话上的最后一个连接(DLC)的设备通过关闭相应的L2CAP通道来关闭multiplexer。

关闭L2CAP通道之前，关闭最后一个连接的设备可能会在DLCI 0上发送DISC命令。另一个设备应使用UA来相应DISC。

Link loss的处理

如果收到L2CAP的link loss指示，本地RFCOMM实体需要负责向每一个DLC上的端口模拟/代理实体发送connection loss指示。之后，与该RFCOMM会话相关的所有资源应该被释放。

对端口模拟/代理实体采取的适当操作取决于顶层API。比如，对于一个模拟串口(vCOMM)，丢掉CD，DSR和CTS信号是适合的(假如设备是DTE)。

系统参数

表5.1包含了GSM 07.10multiplexer的RFCOMM实现所有的使用系统参数。

表5.1系统参数值

注意: 定时器T1是针对P/F-bit置位的frame(RFCOMM中只适用于SABM和DISC frames)。T2是针对于DLCI 0上发送的内置于UIH的命令frame。确切的超时时间取决于实现，可以在上述范围内选择。然而，当发送一个SABM frame去开启一个新的DLC(DLCI > 0)时，T1应该设置成60—300s(再次强调，确切的值依赖于实现)。

由于RFCOMM依赖于较低层提供的可靠传输，以此超时时，默认的操作是关闭multiplexer会话。

在响应端，如果授权过程是由RFCOMM触发，这将只在接收到SABM frame时进行，而不是在接收到准备未打开的DLC的配置命令时执行。

RFCOMM服务器通道的DLCI分配

为了说明客户端和服务器应用程序都可能驻留在RFCOMM会话的两侧，并且任一侧的客户端进行相互独立的连接，DLCI 值使用 RFCOMM 服务器通道和方向的概念在两个通信设备之间划分。

RFCOMM服务器通道是GSM 07.10frame的address字段中的DLCI部分的子集。

表5.2Address字段的格式

使用RFCOMM服务接口的服务器应用注册，会被分配一个服务器通道号码，号码的范围1…30。[因为在GSM 07.10中相应的DLCIs被保留使用，0和31这两个号码不能使用]。该值会被注册进Service Discovery Database，参阅Service Registration and Discovery。

对于一个RFCOMM会话，初始化设备的方向D=1(相反的，另外一端D=0)。在现有的RFCOMM会话上建立一个新的data link连接时，方向bit位和Server Channel一起确定DLCI，用于连接特定的应用程序。此后，DLCI用于端点之间双向的所有数据包。

实际上，对DLCI的划分，在non-initialing设备上的服务应用可用DLCIs 2,4,6,…,60，initialing设备上的服务应用可用3,5,7,…,61。(注意，对于支持多个同步RFCOMM会话的设备，在所有的会话上，方向bit可能都不同)。

RFCOMM实体通过将用于另外的设备的应用程序server channel和这个会话的方向bit取反，从而组成DLCI。

DLCI 1和62-63保留并且没有在RFCOMM中使用。

Multiplexer控制命令

注意，在GSM 07.10中，建立DLC之前，与特定DLCs相关的某些multiplexer control命令可用在DLCI 0上交换。(参考PN和RPN命令)。在接收到DISC命令frame或者从本地关闭DLC时，应将与单个DLC相关的所有此类状态设置为其默认值。这是为了确保同一个会话上的所有DLC建立/重建时，都将有可预测的结果，而不管其之前的会话如何。

如果接收到与未打开的DLCI相关的multiplexer control命令，它的响应实现可能multiplexer control通道上使用DM frame去替换“合适的”响应，并且在referenced DLCI上发送，以此表示DLCI没有开启，并且repsonder也不会批准后续的开启次通道的请求。(也就是说initiator发送的后续SABM将再次被决绝)。