[1]中，第5.4.6.1节规定，运行在一个frame中包含多个multiplexer control消息(只要不超过最大frame大小)。此特性在RFCOMM中是不允许的。(然而，仍然允许RFCOMM实体在其自己的frame中发出多个multiplexer control消息，而无需在其间等待响应)。
Remote Port Negotiation命令(RPN)
RPN命令可以用在新的DLC开启之前，和端口设置发生变化的时候。
RPN命令在GSM 07.10规定中是可选的，在RFCOMM实现中，尽管设置是依赖于实现的，此命令应该要被识别和响应。
Remote Line Status命令(RLS)
此命令用于远程port line的状态显示。
RLS命令在GSM 07.10规定中是可选的，在RFCOMM实现中，尽管设置是依赖于实现的，此命令应该要被识别和响应。
DLC Parameter Negotiation (PN)
PN命令在GSM 07.10规定中是可选的，但是必须用于符合1.2以及更高版本Bluetooth规范的RFCOMM实现。至少在RFCOMM上创建第一个DLC之前使用此命令，并且initiator必须尝试启用credit based flow control，如下所述，在6.5 GSM 07.10并没有明确禁止在任何时候使用，但是在建立DLC之后，PN request的responder可以拒绝更改任何参数(只需要在响应中包含其当前参数集)。
PN命令中有一些参数传递的信息不适用于RFCOMM。因此，发送方应将这些字段设置为预定值，接收方应忽略这些字段。涉及以下字段(见参考文献[1]中的表格3):
- I1-I4应该设置成0。(意义:使用UIH frame)
- T1-T8应该设置成0。(意义:定时器T1的ack，RFCOMM中不可协商)
- NA1-NA8应该设置成0。(意义:重传编号N2;RFCOMM中总是0)
CL1-CL4完全重新定义了。(在GSM 07.10中，这定义了要使用的聚合层，该层不适用于RFCOMM。在RFCOMM中，v1.0B之前版本的蓝牙中，此字段被强制设置成0)。
DLC建立之前发送的PN请求中，此字段应该包含15，表示发送方支持credit based flow control。见表格5.3。如果PN响应在此字段包含14之外的其他任何值，则推断对方的RFCOMM实体不支持credit based flow control功能。(仅当对方RFCOMM实现仅仅符合Bluetooth v1.0B时才有可能)。如果PN是在已经开启的DLC上发送的，则此字段应该是0，每次激活DLC时，不可能多次“设置初始credits”。
当且仅当PN请求中的值是15时，响应实现应该将此字段设置成14。
表5.3 不同版本RFCOMM的CL
*如果请求来自于不支持CFC的1.0B设备
K1-K3完全重新定义了。(在GSM 07.10中，这是错误恢复模式的窗口大小，在RFCOMM中，v1.0B之前版本的蓝牙中，此字段被强制设置成0)。
在PN request/response中，该字段现在被解释成向对方发送给的初始credit额度。因此，此字段可以在request和response中取0-7范围的任何值。
该解释取决于上述CL1-CL4字段的内容，即当未指示credit based flow control时，K1-K3应强制为0。
如果接收到命令的字段中有非法(或由于某些原因不可接收)的值时，则应发出具有responder可以接受的值的DLC参数协商响应，或者responder可以在PN命令中指示的DLC上发送DM frame。响应可以是个PN响应或者DM frame。对于带有N1的N1c(c表示命令)，PN响应应该有N1的N1r(r代表response)，N1r<=N1c。如果接收者因为任何原因不愿意建立起连接，它可以在PN命令指示的DLCI上发送DM frame。
接收PN响应的设备可以接受N1r并且将它用作最大帧数据大小，也可以选择不建立连接。如果它选择不建立连接，则需要发送DISC或者DM frame，以此通知对方。
如果随后建立了此连接，则任何一方都不能发送数据超过N1r字节的frame。
如果在DLC建立之前没有交换PN帧，那么两边实现都应该使用RFCOMM规范中描述的默认值，见表格5.1。
Flow Control
有线端口通常使用诸如RTS/CTS来控制通信。另一方面，RFCOMM和下层L2CAP之间的flow control取决于实现支持的服务接口。此外RFCOMM有自己的flow control机制。这一节就来描述这个不同的flow control机制。
L2CAP Flow Control概览
L2CAP可以使用Link Controller停止和开始flow control机制或者L2CAP per-channel flow control机制。L2CAP和RFCOMM层级之间的flow control机制是特定于实现的。
Wired Serial Port Flow Control
有线端口分为两大类——使用字符(如XON/XOFF)的软件flow control和使用RTS/CTS或者DTR/DSR电路的flow control。这些方法可以在有线链路的两端或者只在一个方向上使用。
GSM 07.10 Flow Control
GSM 07.10协议提供两种flow control机制:
- GSM 07.10协议包含对两个RFCOMM实体之间的综合数据流操作的flow control命令; 所有的DLCIs都会收到影响。定义在参考文献[1]5.4.6.3节中的控制通道命令，FCon和FCoff。
- 定义在参考文献[1]5.4.6.3节中的Modem Status命令，是运行在单独DLCI上的flow control机制。
这些flow control机制只是与除了multiplexer control通道之外的DLCIs上的UIH frame用户负载数据流有关系。支持GSM 07.10-styles的flow control是强制性的，以保持与早期的Bluetooth版本的向后兼容。
当使用MSC2时，在RFCOMM协议层上，只要FC bit才能影响数据流。
RTR bit(以及MSC命令中的其他v.24信号)只能被RFCOMM实体透明地视为“信息”。同时参见图3.1。v.24信号代表应用程序在端口仿真实体之间传递信息，如果已经通过RPN命令完成了协商，同时也可以被解释成“flow control”信息，正如on Port Emulation Entity Serial Flow Control中描述的那样
2如ETSI标准TS 07.10，5.4.6.3.7节中描述，任何情况下，必须在数据传输开始之前交换MSC命令和响应。
Port Emulation Entity Serial Flow Control
在类型1设备上，一些端口驱动程序(Port Emulation Entities plus RFCOMM)将需要提供由其仿真的API指定的flow control服务。应用可以请求特定的flow control机制比如XON/XOFF或者RTS/CTS，并且期望端口驱动处理这个flow control。在类型2设备上，端