RFCOMM协议通过L2CAP协议提供串行端口仿真[2]。该协议是基于ETSI标准GSM 07.10[1]。本文档没有包含完整的规范，而是参考了GSM 07.10标准的相关部分。仅仅使用了GSM 07.10标准的一个子集，并且在本文档中，对该协议做了一些改编。此外，还添加了一个特定于 RFCOMM 的扩展，其形式为强制性的基于信用的流量控制方案。

FRCOMM是一种简单的传输协议，并有模拟RS232(ITU-I V.24)的9针串行端口的附加规定。

RFCOMM协议支持在两个Bluetooth设备之间高达60 路同步连接。Bluetooth设备中可以同时使用的连接数量是特定于实现的。

对于RFCOMM而言，完整的通信路径涉及运行在不同设备(通信端点)上的两个应用程序，它们之间有一个通信段。图1.1展示了完整的通信路径。(这种情况下，Application一词意味着终端用户以外的其他事物，比如代表最终用户应用程序的更高层协议或其他服务)

图1.1:RFCOMM 通信段

RFCOMM旨在涵盖使用其所在设备的串行端口的应用程序。在简单的配置中，通信段是从一个设备到另外一个设备的Bluetooth链路(直接连接)，见图2.2。在通信段是另外一种网络的情况下，Bluetooth无线技术用于设备与调制解调器网络连接设备之间的路径。RFCOMM只关心直接连接情况下设备之间的连接，或者网络情况下设备与调制解调器之间的连接。RFCOMM可以支持其他配置，例如一面通过Bluetooth无线技术通信，另一面提供有线接口的模块，如图1.3所示。这些设备不是正在的调制解调器，但是提供同样的服务。因此这里没有明确讨论它们。

此规范支持如下两种设备类型的实现:

• 第1类设备是通信终端，比如电脑和打印机
• 第2类设备是通信段的一部分，不如调制解调器

尽管RFCOMM在协议中没有对这两种设备加以区分，但是适配中两种设备是会影响到RFCOMM协议的。

图1.2:RFCOMM直连

图1.3:传统COMM设备使用RFCOMM

RFCOMM实体之间传输的信息已经被定义，用以支持两种类型的设备。有些信息只是被第2种设备需要，为另外的在两种设备都可以使用。协议中没有区分类型1和类型2。因此，由RFCOMM的实现者来确定RFCOMM协议中传输的信息是否对实现有用。由于在通信路径中设备不清楚另外设备的类型，因此每个设备应传递协议规定的所有可用信息。

此文档使用与GSM 07.10规范中同样的字节序，比如所有的二进制数都是从Least Significant Bit 到 Most Significant Bit，从左到右读。

RFCOMM模拟RS232(ITU-T V.24)串行端口。包括了对non-data线路状态的传输模拟。RFOMM有一个内置空调调制解调器模拟方案。

如果通过RFCOMM服务接口为特定的端口设置波特率，则不会影响到RFCOMM中实际的数据吞吐量，即RFCOMM不会产生人为的速率限制和调步。然而，如果任一个设备是第2类设备(将数据中继到其他媒体)，或者如果数据调节在任一个或者两端的RFCOMM服务接口之上完成，实际吞吐量将平均翻译波特率设置。

RFCOMM支持两个设备之间的多路串行端口的模拟，并且支持多设备之间的串行端口模拟。

RFCOMM模拟RS-232的9针线路。如下列表中的定义。

表2.1 RFCOMM中模拟RS-232线路

RFCOMM基于GSM 07.10。当需要传输non-data线路状态时，GSM 07.10 没有区分DTE和DCE设备。RS232控制信号作为多个独立的DTE/DCE信号发送，见表2.2。

表2.2 GSM 07.10 串行端口控制信号

两个相同类型的设备连接在一起时，GSM 07.10会通过创建一个隐式的null modem的方式去传输RS-232控制信号。图2.1展示了当两个DTE通过RFCOMM连接在一起所创建的null modem。没有单一的null-modem 布线方案适合所有情况，而RFCOMM中提供的null modem方案在大多数情况下都适用。

图2.1 RFCOMM DTE-DTE null-modem模拟

使用RFCOMM通信的两个Bluetooth设备之间可能会开启多个模拟串行端口。RFCOMM支持多达60个开放的模拟端口，然而一个设备中可以使用的端口数量与具体实现相关。

数据链路连接标识(DLCI) GSM 07.10标识客户端和服务器应用程序之间的持续性连接。DLCI由6bit表示，但是其可用范围为2~61，在GSM07.10中，DLCI 0是专用控制信道，由于服务器通道的概念，DLCI 1不可使用，DLCIs 62-63保留使用。 DLCI在两个设备之间的一个RFCOMM会话中是唯一的(这会在2.3.2节中进一步解释)。为了说明客户端和服务器应用程序都可以驻留在RFCOMM会话的两端，并且任一端的客户请求连接都是相互独立的， DLCI value space 被划分开来，在两个通信设备之间使用RFCOMM服务器通道概念。这将会在5.4章节中进一步描述:RFCOMM服务器通道的分配。

图2.2 两个蓝牙设备的模拟串行端口

如果Bluetooth设备支持多个模拟端口，并且允许连接在不同Bluetooth设备中拥有端点，则RFCOMM实体必须能够允许多个GSM 07.10多路复用器会话，见图2.3。注意每个多路复用器会话使用自己的L2CAP通道ID(CID)。RFCOMM可选择运行GSM 07.10多路复用器的多个会话。

图2.3 多模拟端口

RFCOMM是一个用于模拟串行端口的协议。大多数系统中，RFCOMM是包含串行端口模拟实体的端口驱动的一部分。

图3.1展示了RFCOMM如何适应典型系统的模型。此图表示RFCOMM的参考模型。

图3.1 RFCOMM参考模型

RFCOMM参考模型的元素描述如下:

RFCOMM使用GSM 07.10基础选项。

表4.1展示了RFCOMM支持的GSM 07.10 frame类型

图4.1 RFCOMM支持的frame类型

RFCOMM不支持Unnumbered Information (UI)命令和响应。因此GSM 07.10协议的错误恢复模式选项在RFCOMM中没有使用，相关的frame类型也不支持。

GSM 07.10定义了一个具有专用控制通道DLCI 0的多路复用器。控制通道用于在两个多路复用器之间传输信息。下面是RFCOMM支持的GSM 07.10命令:

每当收到一个non-surpported命令类型时，应该发送一个Non-Surpported命令响应(NSC)。

RFCOMM只支持GSM 07.10中的第一类汇聚层。

调制解调器状态命令(MSC)应用于传输所有模拟串行端口的RS-232控制信号和中断信号。

RFCOMM中不适用GSM 07.10基本选项frame中的打开和关闭标志。相反，标志之间包含的字段才在L2CAP和RFCOMM之间交换，见5.1。

每个L2CAP frame始终只包含一个RFCOMM frame。

图5.1基础选项的frame结构

注意，来自GSM 07.10开启关闭标志是被排除在RFCOMM之外的。

GSM 07.10中，针对不同的frame类型，在不同字段集上计算frame检测序列(FCS)。这些是FCS计算依据的字段:

• 对于SABM,DISC,UA,DM frames: Address, Control和Length字段
• 对于UIH frames: Address和control字段

(这是为了澄清，并为RFCOMM制定标准，FCS计算包含字段在GSM 7.0.0到GSM 07.10中实际发生了变化，但是RFCOMM不会改变上述的FCS计算方案)。

控制字段中(见图5.1)，有一个bit叫做P/F-bit。该bit的一般功能在GSM 07.10[1] 5.4.4节中进行了说明。此外，GSM 07.10[1] 5.4.3.1节中进一步阐明了UIH frame中P/F位的使用值。这些规则适用于不使用基于信用的flow control方案的RFCOMM会话，无需改进。

然而，当基于信用的flow control使用时，P/F-bit的意义在UIH被重新定义了。与图5.1相比较，这还涉及了对框架的重新定义。更多细节参阅DLC Op。

在GSM 07.10中，有两个不同的C/R-bit，一个在frame级(frame header的address字段)，另外一个在message级(多路复用器控制通道发送命令的command type字段)。Frame级的C/R bit与message级的C/R bit是相互独立设置的。

对于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 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。

如果收到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 服务器通道和方向的概念在两个通信设备之间划分。

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中使用。

注意，在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将再次被决绝)。

在GSM 07.10[1]中，第5.4.6.1节规定，运行在一个frame中包含多个multiplexer control消息(只要不超过最大frame大小)。此特性在RFCOMM中是不允许的。(然而，仍然允许RFCOMM实体在其自己的frame中发出多个multiplexer control消息，而无需在其间等待响应)。

RPN命令可以用在新的DLC开启之前，和端口设置发生变化的时候。

RPN命令在GSM 07.10规定中是可选的，在RFCOMM实现中，尽管设置是依赖于实现的，此命令应该要被识别和响应。

此命令用于远程port line的状态显示。

RLS命令在GSM 07.10规定中是可选的，在RFCOMM实现中，尽管设置是依赖于实现的，此命令应该要被识别和响应。

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。

有线端口通常使用诸如RTS/CTS来控制通信。另一方面，RFCOMM和下层L2CAP之间的flow control取决于实现支持的服务接口。此外RFCOMM有自己的flow control机制。这一节就来描述这个不同的flow control机制。

L2CAP可以使用Link Controller停止和开始flow control机制或者L2CAP per-channel flow control机制。L2CAP和RFCOMM层级之间的flow control机制是特定于实现的。

有线端口分为两大类——使用字符(如XON/XOFF)的软件flow control和使用RTS/CTS或者DTR/DSR电路的flow control。这些方法可以在有线链路的两端或者只在一个方向上使用。

GSM 07.10协议提供两种flow control机制:

1. GSM 07.10协议包含对两个RFCOMM实体之间的综合数据流操作的flow control命令; 所有的DLCIs都会收到影响。定义在参考文献[1]5.4.6.3节中的控制通道命令，FCon和FCoff。
2. 定义在参考文献[1]5.4.6.3节中的Modem Status命令，是运行在单独DLCI上的flow control机制。

这些flow control机制只是与除了multiplexer control通道之外的DLCIs上的UIH frame用户负载数据流有关系。支持GSM 07.10-styles的flow control是强制性的，以保持与早期的Bluetooth版本的向后兼容。

当使用MSC²时，在RFCOMM协议层上，只要FC bit才能影响数据流。

RTR bit(以及MSC命令中的其他v.24信号)只能被RFCOMM实体透明地视为“信息”。同时参见图3.1。v.24信号代表应用程序在端口仿真实体之间传递信息，如果已经通过RPN命令完成了协商，同时也可以被解释成“flow control”信息，正如on Port Emulation Entity Serial Flow Control中描述的那样

²如ETSI标准TS 07.10，5.4.6.3.7节中描述，任何情况下，必须在数据传输开始之前交换MSC命令和响应。

在类型1设备上，一些端口驱动程序(Port Emulation Entities plus RFCOMM)将需要提供由其仿真的API指定的flow control服务。应用可以请求特定的flow control机制比如XON/XOFF或者RTS/CTS，并且期望端口驱动处理这个flow control。在类型2设备上，端口驱动需要在通信路径的non-RFCOMM部分执行flow control，比如物理RS-232端口。此flow control通过对方的RFCOMM实体(通常为1类设备)发送的控制参数指定。本节flow control描述就是针对类型1设备端口驱动的。

由于RFCOMM已经有了自己的flow control机制，因此端口驱动不需要使用应用程序请求的方法执行flow control。理想情况下，应用程序设置一个flow control机制并且架设操作系统将处理细节。端口驱动可以简单的忽略该请求并依赖RFCOMM的flow control。应用程序能够发送和接收数据，并且不知道或不关心端口驱动程序没有使用请求的机制执行flow control。然而，在现实世界中出现了一些问题。

• 基于RFCOMM的端口驱动程序运行在基于数据包的协议之上，在该协议中，数据可以在通信路径的某个位置进行缓冲。因此，端口驱动程序无法以与有线情况下相同的精度执行flow control。
• 除了从端口驱动程序请求flow control之外，应用程序本身还可以决定应用flow control机制。

这些问题表明端口驱动程序必须做一些额外的工作才能正确地执行flow control仿真。下面是基础的flow control仿真规则。

• 端口驱动程序将不仅仅依赖于应用程序请求的机制，而是使用flow contro机制的组合。
• 端口驱动程序必须知道应用程序所请求的flow control机制，并且当它看到传入数据中的非数据电路(硬件flow control)或流控制字符(软件flow control)发生变化时，其行为与有线情况类似。例如，如果XOFF和XON字符在有线情况下已被剥离，则必须由基于RFCOMM的端口驱动程序剥离它们。
• 如果应用程序通过端口驱动程序接口设置flow control机制，然后继续自行调用该机制，则端口驱动程序的行为必须与有线情况下的行为类似（例如，如果在有线情况下XOFF和XON字符会传递到有线，则端口驱动程序也必须传递这些字符）。

应用这些基本规则来模拟每个有线flow control方案。请注意，可以同时设置多种类型的流量控制。参考文献[1] 5.4.8节定义了每一个flow control机制。

这是Bluetooth规范v1.0B及更早版本中RFCOMM中不存在的强制功能。因此，它的使用需要在第一次建立数据链路之前进行协商(参见数据链路参数协商(PN)和初始数据链路协商)。符合本规范的实施应支持它，并应在连接到其他设备时尝试使用它。

credit based flow control功能在per-DLC基础上提供flow control。使用时，RFCOMM会话中涉及的两个设备都将知道，对于每个DLC，在其缓冲区填满该DLC之前，另一个设备能够接受多少RFCOMM帧。一个发送实体可以在一个DLC上发送尽可能多的帧，只要它有credit，如果credit计数为零，发送方应停止并等待对等方的更多的credit。在使用credit based flow control时，始终允许发送不包含用户数据的帧(长度字段=0)。该机制针对每个DLC和每个方向独立运行。它不适用于DLCI 0或非UIH帧。

使用credit based flow control是会话的一个特点。因此，在建立第一个DLC之前，必须使用PN multiplexer control命令协商(参见DLC参数协商(PN))。

在首次成功协商和DLC建立后，所有DLC都将使用此方案进行flow control。后续DLC建立的PN协商是可选的，但建议进行协商，因为它还为双方建立初始credit计数值

当使用credit based flow control时，RFCOMM头的控制字段中的P/F位的含义将针对UIH frame重新定义。

当UIH frame中的P/F位为零时，frame的结构如图5.1所示。当P/F位在UIH frame中为1时，帧的结构如下图6.1所示。在这种情况下，在长度指示器和有效载荷信息字段之间插入credit字段。credit八位字节(0-255)的值表示多个帧，对于这些帧，发送方可以在DLC上接收缓冲区空间。(每个frame的大小可达到商定的最大frame大小)。credit是累加的，这意味着收到的credit将添加到之前可能剩下的任何剩余credit中。在这种情况下，长度指示符字段(一如既往)指示以下信息字段中的信息八位字节数；然而，允许的最大信息八位字节数减少了一个，以补偿credit字段。这是为了保持最大L2CAP有效负载大小不变）。这意味着，对于P/F位=0的UIH帧，信息字段的最大大小是协商的大小(=N1参数)，而对于P/F位=1的UIH帧，实际最大大小是少一个(N1-1)。

图6.1 基础选项的frame结构，credit-based flow control使用时，P/F-bit=1的UIH frames

在会话中使用credit-based flow control时，以下情况适用：

• FCon/FCoff multiplexer control命令不应使用
• MSC命令中的FC-bit没有意义，MSC命令中应该被设置成0，并且接受方应该忽略它。
• 自v1.1起，FCon/FCoff multiplexer control命令和MSC flow control命令不再推荐使用。

本节定义了如何使用RFCOMM协议来模拟串行端口。

图7.1显示了RFCOMM协议支持的两种设备类型。

图7.1 RFCOMM通信模型

类型1设备是通信终端设备，比如电脑和打印机。类型2设备是通信组件比如modem。

端口仿真实体将特定于系统的通信接口(API)映射到RFCOMM服务。

端口代理实体将数据从RFCOMM中继到链接到DCE的外部RS-232接口。根据接收到的RPN命令设置RS-232接口的通信参数；见第5.5.1节。

各个应用程序或服务的注册以及访问这些应用程序或服务所需的信息(即RFCOMM服务器通道)分别由每个应用程序(或可能是代表不直接了解Bluetooth的遗留应用程序的Bluetooth配置应用程序)负责。

下面是使用RFCOMM为给定service或profile开发服务记录的模板/示例。它说明了如何包含只有一个service 类的ServiceClassList，和两个协议的ProtocolDescriptorList(尽管在RFCOMM之上可能有更多协议)。该示例显示了另一个通用属性(ServiceName)的使用。对于在RFCOMM之上运行的每个服务，将应用适当的SDP定义的通用属性和/或特定于服务的属性。有关服务记录的更多信息，请参阅SDP规范[3]，第2.2节。

客户端应用程序连接到RFCOMM之上的服务所需的属性(至少)是ServiceClassIDList和ProtocolDescriptorList(对应下表中的阴影行)。

注意:

定义见“Bluetooth Assigned Numbers”[4]

1. 对于所有“可显示”文本字符串属性的国家语言支持，必须将偏移量添加到所选语言的LanguageBaseAttributeIDList值中(有关详细信息，请参阅SDP规范第5.1.14节)。
2. 为特定服务定义(如有必要)。
3. 对于特定服务，一些SDP定义的通用属性可能适用。见SDP规范，第5.1节。
4. 这表示服务类别。它可以是单个条目，也可以是从通用的到最特定的服务类列表。

RFCOMM使用L2CAP的服务建立L2CAP通道，以连接其他设备上的RFCOMM实体。L2CAP信道用于RFCOMM/TS 07.10 multiplexer会话。在这种信道上，进行第5.1节中定义的自适应，并发送第4.2节中列出的GSM 07.10 frame。

某些frame类型（SABM和DISC）以及在DLCI 0上发送的带有multiplexer control命令的UIH frame始终需要远程实体的响应，因此它们在RFCOMM级别得到确认(但在没有确认的情况下不会重新传输；参见第5.3节)。数据frame在RFCOMM协议中不需要任何响应，因此是未被确认的。

因此，RFCOMM应配置L2CAP，以提供可靠的信道，确保所有frame有序交付，且无重复。为了实现这一点，可以使用L2CAP错误控制机制，或者必须将flush timeout配置为无限。

如果指向某个设备的所有L2CAP信道空闲一定时间，可以决定将该设备设置成低功率模式（即使用hold、sniff或park，请参阅“Baseband Specification”第10.10.3节）。这将在不受RFCOMM干扰的情况下完成。RFCOMM可向L2CAP说明其延迟要求。较低层可以使用此信息来决定使用哪种低功耗模式。

RFCOMM协议不会因为低功率模式而产生延迟，因此，本规范不会代表RFCOMM说明任何最大延迟要求。延迟敏感度本质上取决于应用程序需求，这表明RFCOMM服务接口实现可以包括一种应用程序状态延迟需求的方法，由RFCOMM实现聚合并传递给L2CAP。(如果此类程序对特定平台有意义的话。)

[1] GSM 07.10, v6.3.0, ETSI

[2] Bluetooth Core Specification v2.0 + EDR and later, Volume 3, Part A (L2CAP)

[3] Bluetooth Core Specification v2.0 + EDR and later, Volume 3, Part B (SDP)

[4] Bluetooth Assigned Numbers

下列的专业术语在全文中使用: