省略了前面的格式。
全文下载：
前言
如果设备符合蓝牙SIG定义的配置文件规范，则为来自不同制造商的设备之间的互操作性提供了特定的服务和用例。配置文件从蓝牙SIG规范中定义了可选择的消息和程序（通常称为能力），并提供了针对指定服务和用例的空中接口的明确描述。
所有已定义的特性都是过程强制性的。这意味着如果使用一个特性，则以指定的方式使用。无论蓝牙空中接口两侧分别规定的功能是强制性还是可选性。
1.简介
1.1.范围
串口配置文件定义了使用蓝牙进行RS232（或类似的）串口电缆模拟的设备应使用的协议和程序。
此概要文件所涵盖的场景通过虚拟串口抽象（其本身依赖于操作系统）来处理遗留的应用程序，使用蓝牙作为电缆替换。
1.2.蓝牙配置文件结构
在图1.1中，描述了蓝牙配置文件的结构和这些配置文件之间的依赖关系，如果一个配置文件通过隐式或显式引用该概要文件的部分，那么它依赖于另一个配置文件。依赖关系如图所示：配置文件对其中包含它的配置文件具有直接或间接的依赖关系。
图1.1：蓝牙配置文件
1.3.符号和约定
此配置文件使用通用访问配置文件[9]第1.2节中指定的符号和约定。
2.配置文件概述
2.1.配置文件栈
图2.1显示了在此配置文件中使用的协议和实体。
图2.1：协议模型
基带[1]LMP[2]和L2CAP[3]是OSI第1层和第2层蓝牙协议。RFCOMM[4]是GSMTS07.10[5]的蓝牙适配，为串口仿真提供传输协议。SDP是蓝牙服务发现协议[6]。
图2.2中所示的端口仿真层是模拟串行端口的实体，或者为应用程序提供API。
双方的应用程序通常都是遗留的应用程序，能够并希望通过串行电缆进行通信（在这种情况下是模拟的）。然而，遗留应用程序不知道设置模拟串行电缆的蓝牙过程，这就是为什么它们需要双方某种具有蓝牙感知的辅助应用程序的帮助（这些问题在此配置文件中没有明确地加以解决，这里的主要问题是蓝牙的互操作性）。同样，希望通过蓝牙执行串行通信的非遗留应用程序也必须遵守此配置文件中指定的行为，无论它们是否使用了如上所述的蓝牙感知助手，情况都是如此，或者通过使用其他接口到蓝牙堆栈。这确保了遗留和非遗留应用程序的所有组合在蓝牙级别上保持可互操作性。
2.2.配置和角色
图2.2显示了此配置文件的一种可能的设备配置
图2.2：串口配置文件，具有两个笔记本的示例。
为此配置文件定义了以下角色：
设备A(DevA)-这是主动与另一个设备建立连接的设备(DevA是GAP[9]第2.2节中的发起者)。
设备B(DevB)-这是等待另一个设备主动连接的设备。(DevB是GAP[9]中第2.2节中的接受者)。
请注意，连接的顺序(从DevA到DevB)并不一定与遗留应用程序在每边分别启动的顺序有关。
信息说明：为了将串口配置文件映射到传统的串口体系结构，DevA和DevB都可以是DCE(Data Circuit Endpoint )或DTE(Data Terminal Endpoint)。(RFCOMM协议被设计独立于DTE-DCE或DTE-DTE关系。)
2.3.用户需求和场景
此配置文件所涵盖的场景如下：
在两个设备（例如pc）上设置虚拟串行端口（或同等端口），并通过蓝牙连接，以模拟两个设备之间的串行电缆。任何遗留应用程序都可以在任何一个设备上运行，使用虚拟串行端口，就好像有一个真正的串行电缆连接这两个设备(使用RS232控制信令)。
此配置文件只需要支持单个时隙数据包。这意味着该配置文件确保可以使用高达128kbps的数据速率。支持更高的费率是可选的。
在此配置文件中，一次只处理一个连接。因此，只考虑点对点配置。然而，这不应被解释为对同时连接的强迫和限制；此配置文件的多个执行应该能够在同一设备中并发运行，这还包括同时承担两个不同的角色(如DevA和DevB)。
附注：也就是一个profile只对应一个虚拟串口，但是可以同时运行多个profile实现多个串口。
2.4.配置文件基础
为了执行此配置文件，使用诸如授权、身份验证和加密等安全特性是可选的。身份验证和加密是强制的，这样，如果从对等设备中提出请求，设备可以参与相应的过程。如果需要使用安全特性，则在连接建立阶段（如果不是更早）将两个设备配对，参见GAP，第7节。在此配置文件中没有明确地使用绑定，因此，对绑定的支持是可选的。链路的建立是由DevA发起的。必须执行服务发现过程，以建立一个模拟的串行电缆连接。
没有固定的主从属角色。
RFCOMM用于传输用户数据、调制解调器控制信号和配置命令。
2.5.一致
当声明符合此配置文件时，此配置文件的所有强制功能应以规定的方式支持（过程强制）。这也适用于所表示支持的所有可选功能和条件功能。所有的强制性功能、可选功能和有条件的功能，都需要作为蓝牙认证计划的一部分进行验证。
3.应用层
本节描述了符合串口配置文件单元的特性要求。
此配置文件建立在通用访问配置文件(GAP)之上。
当读取[9]时，甲方（连接启动器）相当于DevA，而乙方相当于DevB
在[9]中定义的所有强制性要求对于此配置文件都是强制性的。
除非下面另有说明，否则在[9]中定义的所有可选要求都是此配置文件的可选要求。
3.1.流程概述
表3.1显示了所需的程序：
流程 | DevA的支持 | DevB的支持 | |
1 | 建立链接并设置虚拟串行连接 | M | X |
2 | 接受链接并建立虚拟串行连接。 | X | M |
3 | 本地SDP数据库中注册应用程序的服务记录 | X | M |
表3.1：应用层程序
3.1.1.建立链接并设置虚拟串行连接
此过程是指执行在远程设备中建立到模拟串口（或等同）的连接所需的步骤。本过程中的步骤包括：
1.使用SDP提交一个查询，以查找远程设备中所需应用程序的RFCOMM 服务通道号。这可能包括一种浏览功能，可以让用户在对等设备中的可用端口（或服务）中进行选择。或者，如果确切地知道要联系哪个服务，那么使用与所需服务关联的服务类ID来查找必要的参数就足够了。
2.或者，需要对要执行的远程设备进行身份验证。也可以选择，需要打开加密功能
3.向远程RFCOMM实体请求一个新的L2CAP通道
4.在L2CAP通道上启动一个RFCOMM会话
5.使用上述的服务器通道号，在RFCOMM会话上启动一个新的数据链路连接
在步骤5之后，虚拟串行电缆连接可以用于两侧应用程序之间的通信。
注意：如果在设置新的数据链路连接时，两个设备之间已经存在一个RFCOMM会话，则必须在现有的RFCOMM会话上建立一个新的连接。（这相当于跳过上面的步骤3和步骤4。）
注意：步骤1和步骤2之间的顺序并不重要（可能正好相反）。
3.1.2.接受链接并建立虚拟串行连接
本过程是指针对以下步骤：
1.如果远程设备请求，请参与认证过程，并在进一步请求时打开加密。
2.接受来自L2CAP的新通道建立指示
3.接受该通道上的RFCOMM会话建立
4.在RFCOMM会话上接受一个新的数据链接连接。如果用户要求连接所连接的模拟串口（并且尚未执行身份验证/加密过程），这可能会触发身份验证远程设备并打开加密的本地请求
注意：当已经存在到远程设备的RFCOMM会话时，步骤1和步骤4可能是孤立事件。
3.1.3.在本地SDP数据库中注册应用程序的服务记录
此过程是指在SDP数据库中注册模拟串口（或等效端口）的服务记录。这意味着存在一个服务数据库，以及响应SDP查询的能力。
通过RFCOMM可访问的所有服务/应用程序都需要提供一个SDP服务记录，其中包括访问相应的服务/应用程序所需的参数，请参见第6.1节。为了支持在虚拟串口上运行的遗留应用程序，服务注册必须由一些辅助应用程序来完成，它可以帮助用户设置端口
3.2.电源模式和链路损耗处理
因为在串口配置文件中活动的单元的功率需求可能大相径庭，它不需要使用任何一种节能模式。但是，如果可能，使用低功率模式的请求不应被拒绝。
如果使用sniff, park, hold模式，则不释放RFCOMM DLC和L2CAP通道。
如果一个单元检测到链路的丢失，RFCOMM应被认为已被关闭。不得执行第4节中所述的断开DLC和关闭RFCOMM程序。在恢复更高层上的通信之前，必须执行初始化RFCOMM会话过程
4.RFCOMM互操作性要求
本节描述了在符合串口配置文件的单元中对RFCOMM的要求。
表4.1：RFCOMM功能
M1：在RFCOMM协议中，同时操作多个RFCOMM会话的能力是可选的。尽管在有意义的地方鼓励支持并发性，但此配置文件并不要求在DevA或DevB中支持并发的RFCOMM会话。
X1：在执行此配置文件中定义的角色的过程中，将不会使用这些能力
N/A1：RFCOMM协议中未确认的信息传输。
C1：使用哪种流量控制机制（每个DLC、集合或两者都使用）是一个实现问题。但是，如果实现不能保证接收到的数据总是有可用的缓冲区，则必须能够发送每个DLC流量控制或集合流量控制
其中一些程序将在下面的小节中进行进一步的评论
4.1.RS232控制信号
根据TS07.10[5]，第5.4.6.3.7节，所有的设备都需要通过调制解调器状态命令发送关于RS232控制信号中所有变化的信息。
然而，由于RFCOMM可以与实现任何类型API的自适应层一起使用（不仅仅是虚拟串口），使用除流量控制(TS07.10[5]中的RTR信号)外的所有RS232控制信号是一个可选项。这个信号可以被映射到RTS/CTS或XON/XOFF或其他API机制上，这是一个实现问题。
信息说明：为了提供实际使用所有RS232控制信号的设备和未使用它们的设备之间的互操作性，前一种实现必须根据RFCOMMDLC状态将api/连接器中适当信号的状态设置为适当的默认值。该实现不能依赖于从对等设备接收任何RS232控制信息。对RFCOMM DLC状态的依赖可能意味着，当一个RFCOMM DLC建立时，DSR/DTR和DCD被设置为高电平，如果相应的DLC因任何原因关闭，相同的信号被设置为低电平。
4.2.远程线路状态指示
如果本地设备从物理串口（或同等）中继信息可能发生溢出、奇偶或帧错误，需要使用远程线路状态指示命令通知其他设备RS232线路状态的任何变化，请参见[5]第5.4.6.3.10节。
4.3.远程端口协商
DevA可以在DLC建立之前，直接通过远程端口协商命令通知DevB RS232端口设置。参见[5]，5.4.6.3.9节。如果到RFCOMM自适应层的API公开了这些设置（例如波特率、奇偶校验），则需要这样做。
DevB允许发送远程端口协商命令
信息说明：根据RFCOMM[4]第1.2节，远程端口协商过程中传递的信息预计仅在II类设备（具有物理串行端口）中有用，或者由于任何原因在模拟串行端口接口上进行数据限速。因此不会基于波特率设置人为限制吞吐量，参见RFCOMM[4]第2章5.L2CAP的互操作性要求
以下文本和相关的子条款定义了关于此profile的强制性要求
表5.1：L2CAP程序
X1：在此配置文件的执行过程中不使用无连接通道，但不排除其他配置文件/应用程序的并发使用。
5.1.通道类型
在此配置文件中，只能使用面向连接的通道。这意味着在此配置文件中将不使用广播数据和单播无连接数据。
在连接请求数据包的PSM字段中，必须使用分配编号文档[8]第3.2节中定义的RFCOMM值
5.2.信号
只有Dev A可以在执行此配置文件时发出L2CAP连接请求。除此之外，串口配置文件并没有对L2CAP信令施加任何额外的限制或要求
5.3.配置选项
本节介绍了串口配置文件中的配置选项的使用情况
5.3.1.最大传输单元-MTU
根据L2CAP[3]第6.1节中规定的限制，本配置文件对MTU大小没有施加任何限制。
5.3.2.刷新超时
串口数据通过一个可靠的L2CAP通道传输。刷新超时值应设置为其默认值0xffff，除非为L2CAP通道承载RFCOMM协商了L2CAP增强重传模式（见第5.3.4节）。如果协商了L2CAP增强重传模式，则可以根据在同一ACL逻辑传输上运行的其他配置文件来设置刷新超时值。
5.3.3.服务质量
关于服务质量的协商是可选的
5.3.4.流控和错误控制
对于任何将传输大型数据文件和接收设备将受到无线电干扰导致数据包丢失的产品，建议通过配置信道以使用增强重传模式来利用L2CAP(核心规范V3.0及以后)中的错误控制特性。
串口数据通过一个可靠的L2CAP通道传输。该通道的可靠性可以通过在ACL逻辑传输上的无限刷新超时来实现。但是，如果串口配置文件与同一物理链路上的其他配置文件共存，那么可能不能以这种方式配置ACL逻辑传输。因此，对于期望串口配置文件与物理链路上的其他配置文件共存的设备，应为通道承载RFCOMM协商L2CAP增强重传模式（在核心规范版本3.0中引入）。以这种方式实现可靠的L2CAP通道，允许ACL逻辑传输具有适合于其他配置文件的有限刷新超时。
L2CAP增强重传模式也可以协商为使用串口配置文件的应用程序，这需要比非刷新ACL逻辑传输提供的更高的可靠性。
6.SDP的互操作性要求
6.1.串口配置文件的SDP服务记录
在Dev A中没有与串口配置文件相关的SDP服务记录。
下表是对Dev B的SDP数据库中的串口相关条目的描述。允许向此服务记录添加其他属性
在v1.2之前的串口配置文件版本没有强制使用BluetoothProfileDescriptorList属性。新的Dev A设备应假定没有此属性的远程Dev B不支持串口配置文件版本1.2或更高版本
表6.1：SDP服务记录
备注：
1.已在“已分配的编号”文档[8]中定义。
2. 对于支持所有“可显示”文本字符串属性的国家语言，必须在所选语言的语言基础属性ID列表值中添加一个偏移量(详情请参见SDP规范[6]，第5.1.14节)。
3.“串口”服务类是最通用的服务类型。此配置文件不排除添加其他更特定的服务类。
4.此处建议的服务名称属性值只是一个示例；设置串口的辅助应用程序可以为该端口提供更具描述性的名称
6.2.SDP程序
为了检索支持此配置文件的服务记录，DevA中的SDP客户端实体通过SDAP[7]第5节和第6节中介绍的SDP和L2CAP程序与DevB中的SDP服务器实体进行连接和交互，DevA扮演本地设备的角色，而DevB扮演远程设备的角色。
7.链接管理器(LM)互操作性要求
7.1.能力概述
除了在链接管理器规范本身中规定的对支持的过程的要求外（参见[2]中的第3节），这个配置文件还需要支持DevA和DevB中的加密。
7.2.错误行为
如果一个单元试图使用强制功能，而另一个单元回答不支持，启动单元应发送一个具有分离原因的LMP_detach“不支持LMP功能”。
一个单元应始终能够处理对一个可选功能的请求的拒绝。
7.3.链接策略
没有用于执行此配置文件的固定主从角色。
此配置文件不说明是否使用低功耗模式或何时使用时的任何要求。这是由每个设备的链接管理器在第5.3.3节中规定的延迟要求的限制范围内，适当地决定和请求的。
8.链接控制(LC)互操作性要求
8.1.查询
在DevA中调用查询时，应使用一般查询程序；参见GAP[9]第6.1节。
只有DevA可以在此配置文件的执行过程中进行查询
8.2.查询扫描
对于查询扫描，（至少）应根据GAP[8]第4.1.2节和第4.1.3节中定义的可发现模式之一，使用GIAC。也就是说，如果适合驻留在DevB中的应用程序，它只允许使用有限的可发现模式。
在DevB查询响应消息中，“设备类”字段不会包含任何提示DevB是否正在执行串口配置文件（由于此配置文件提供的遗留应用程序的通用串口服务不适合“设备类”字段定义中的任何主要服务类位）。
寻呼
只有DevA可以在此配置文件的执行中page。当DevA和DevB之间已经存在基带连接时，当开始执行此配置文件时，将在DevA中跳过page步骤。(在这种情况下，连接可能是DevB之前page后设置的。
附注：进行连接/激活对应的slave的操作我们就称为page。它是指：发起连接的设备（主设备）知道要连接设备的地址。所以可以直接传呼
8.3.错误行为
由于LC级别上的大多数特征必须由LMP程序激活，因此错误大多会在该层被捕获。然而，也有一些独立于LMP层的LC程序；例如，查询或page。滥用这些特征是很困难的，有时甚至不可能检测到。没有定义的机制来检测或防止这种不当使用。
