在开发 BLE 连接产品的过程中，你可能会有这样的疑问："Serial profile在哪里？也许你以为你在蓝牙技术联盟网站上滚动浏览长长的profile列表时错过了它。又或者，你根本就没去看，而是准备选择更快的方法，即芯片组提供的串行 API实现。而实际上，这两种方法都不行，官方蓝牙配置文件是不支持串行 Rx/Tx的。
那么，蓝牙低功耗串口是否只是那些不愿意学习蓝牙方法的人使用的差劲手段？或者，蓝牙低功耗串行策略是否能带来合理的好处？
下一次为您的互联产品设计通信策略时，请记住以下几点：
蓝牙低功耗 (BLE) 是作为蓝牙（现在的蓝牙经典）的低功耗替代品而设计的。BLE 允许设备在使用纽扣电池的情况下通信数年。BLE 通过专注于尽可能高效地发送小块(chunks)数据来实现这一目标。为了实现这种效率，我们采用了一种名为 "属性协议"（Attribute Protocol - ATT）的客户端-服务器架构。
ATT 由Services服务、Characteristics特征和Descriptors描述符组成。对这些对象中的每一个都可称为profile配置文件。描述符属于特征，表示该特征的属性。特征具有一种状态，在不同状态下，客户端通过读取、写入或订阅其变化来与服务端的特征进行交互。服务是若干的特征组。
BLE 听起来一点也不像串行协议，不是吗？这是因为与串行数据包相关的所有开销都被抽象化了，只留下一个简单的读、写和通知接口。尽管如此，芯片制造商们还是接受了 BLE 串口协议，并各自在其芯片组上实现 BLE 串口协议，创建了自定义的配置文件（customer profiles）和 API。
Microchip Technology 的 Transparent UART Service、Nordic Semiconductor 的 Nordic UART Service 和 Texas Instruments 的 Serial Port Service 只是为 BLE 串口创建的定制配置文件中的几种。它们这样做是有道理的，因为为您的蓝牙低功耗产品选择BLE串口通讯(Serial over BLE)有很多好处。
注：BLE串口通讯指的是由单个service组成的 ATT 设计，这个service包含一个仅允许通知/指示(notify/indicate)的 RX 特性，还有一个仅允许写入的 TX 特性。
使用蓝牙低功耗串口的原因
使用蓝牙低功耗串行协议的主要原因是它更易于使用。对于嵌入式工程师来说，设计和使用串行协议就像呼吸一样简单。坚持使用熟悉的协议，开发速度会更快，最终产品也更可靠。
除了熟悉之外，使用 BLE 串口还意味着通过 BLE 发送的应用数据格式可与其他有线和无线传输协议（UART、SPI、Wi-Fi 等）互操作。因此，当 BLE 协议栈与主应用程序位于不同的处理器上时，BLE 串口也具有巨大的优势。
在独立于主应用程序的处理器上运行 BLE 堆栈是一种常见的嵌入式架构策略。这些 BLE 协处理器的复杂程度各不相同，有的是完整的 SoC，有的则是专用的 BLE 堆栈，但都足以完成工作。
无论硬件的功能如何，如果处理器不运行主应用程序，那么简单地配置 BLE 芯片并将其作为另一条 UART 线路进行交互就非常有吸引力。更改数据包协议、发送新的数据类型以及调整数据包结构（ packet infrastructure，如长度字段或数据包标识符字段）都可以在不更改 BLE 协处理器上任何内容的情况下完成，因为协处理器并不关心发送的内容，它只是转发所有内容。
BLE 串口一般可以更快地建立连接。如上图所示，连接建立时间往往与发现的服务、特征和描述符的数量成线性关系。
"Discovering发现 "指的是映射出所有服务、特性和描述符的句柄，以便应用程序知道它们是什么，并能在以后引用它们。在连接启动时，每发现一个额外的服务、特性或描述符，就需要增加一到三个连接时间间隔，然后才能使用连接传输应用程序数据。
iOS 系统的连接时间间隔(Connection intervals)一般为 30 毫秒，但在 Android 系统上可低至 7.5 毫秒。BLE 串口架构只需使用一种服务和两种特性，即可传输大量的各式各样数据。
蓝牙低功耗串行通信的缺点
几乎所有形式的数字通信都基于串行协议，并具有不同的封装级别，甚至蓝牙经典协议也不例外。
那么，为什么不能将低功耗蓝牙用作简单的无线 UART 链路(link)呢？
串行比 BLE 的最大缺点(most considerable downside)是应用延迟(higher application latency)更高。应用延迟的增加会导致用户体验不佳，并浪费或占用了一些时间，这些时间本来是设备可以进入低功耗状态来节能的。
如图上图所示，收到请求后，必须将其传递给外设应用层（peripheral’s application layer）执行。执行请求后，必须将响应封装到适当的数据包中。然后将响应数据包交给外设的 BLE 堆栈，由其向中心设备发送指示(sends an indication to the central)。
即使外设应用程序直接从内存中返回数据，中心设备也至少需要两个连接间隔才能收到所请求的数据。考虑到在大多数情况下，应用程序向 BLE 层发出的每个请求都需要排队，因此中心设备收到其发出请求的响应所花费的时间，通常还会需要更多个连接间隔。
对于标准的 BLE 读取请求，如上图所示，外设应用程序会不断更新特征的状态。读取时，特征已包含所请求的数据，并立即做出响应。请求和响应保持在一个连接间隔内。
BLE 串行模式的应用延迟也更高，因为连接中的两个设备都不能过滤掉它们不感兴趣的数据种类。因此，所有数据包都必须通过 BLE 发送并传递到应用层，然后才能丢弃不重要的数据包。
BLE 串行策略中浪费时间和电流的另一个因素是在应用层为数据包所增加的开销。数据包标识符、长度字段和校验和都是在 BLE 串行策略中添加到应用层数据包的字段。同样的字段也会添加到封装的 BLE 数据包中。这些重复的字段为 BLE 无线电传输增加了更多比特，但其价值微乎其微，因为 BLE 协议有自己的机制来处理各种相应问题。
如果您的 BLE 产品打算与运行 iOS 和 Android 的设备进行通信，那么还有其他一些注意事项需要牢记。首先，复杂的数据包协议需要更详尽的文档，以便开发人员（很可能在不同的团队中）参照使用。BLE 数据包串行还要求移动应用程序有一个中央数据包处理基础架构来检查所有种类的数据包协议，以便知道如何解析出有用信息并将其发送到哪里。最后，移动编程语言(mobile programming languages, 比如Android的。)很难处理小于一个字节的对象，因此 BLE 串行数据包只能由字节大小的数据单位构成。
BLE 串行数据包的最后一个缺点是，使用自定义数据包协议严重限制了与其他 BLE 软件的互操作性。随着 BLE 无线电设备数量的增加，我们不难想象设备与其合作伙伴应用程序和其他基于 BLE 的系统进行通信的可能性；这才是蓝牙技术联盟配置文件(profiles)真正强大之处，能够实现统一的profiles。
在互联产品中，我们应该选择使用什么技术(What Should You Use in Your Connected Product)
既然您已经知道 BLE串行通信策略的优缺点，你可能会问："对我们的产品来说，在设计上我该如何做出正确决定？"
答案在很大程度上取决于设计者，因为无论采用哪种方法，都能做出一个可用的产品，完成设计任务。然而，设计方法既会影响产品开发的难易程度，也会影响产品的性能。
在比较通信策略时，首先要考虑的是产品的现实条件限制(physical constraints)。如果吞吐量是您的首要考虑因素，那么串行通信策略可以让您在最短的时间内传输最多的数据，尤其是在大部分数据都是单向流动的情况下。你需要了解如何从 BLE 无线电（radio）中获得最大性能。如果您的蓝牙模块处理能力不足，那么使用该蓝牙模块的最简单接口方式，就是使用串行通信策略的接口。
上面的情况是倾向于使用BLE串行通讯的。如果你正在构建的产品的硬件方案的现实条件的约束不是问题，那么你应该将重点放在用户体验(UX, user experience)限制上: 延迟（latency）。
良好的用户体验首先来自于制造出每次都能正常工作、使用简单（intuitive ）的设备。当然需要保证的是，延迟不会影响良好的用户体验。在这种情况下，我们要优化的是连接延迟与应用延迟(connection latency vs. application latency)。
连接延迟是指连接到应用数据传输点所需的时间。另一方面，应用延迟是指从应用向连接设备发出请求到应用得到响应所需的时间。
连接延迟可通过使用更快的广播速率(Advertising rates)、使用更少的服务和特性来改善，就如在 BLE 串行策略中所用的。但是，使用BLE 串行协议是以应用程序延迟为代价的，尤其是在默认情况下，信息流在连接过程中是持续不断的。
使用客户端-服务器设计可避免这种应用延迟，并有助于提供闪电般快速的响应。对于使用的连接保持很长(long-running connections)的设备来说，连接设置时间和应用程序延迟之间的权衡是很容易的( the tradeoff between connection setup time and application latency should be a no brainer)。你可以多添加些特性。
混合模式： 两全其美 （Hybrid Models: The Best of Both Worlds）
BLE 串行策略和客户端-服务器方法是光谱的两端。对于许多产品来说，最佳设计介于两者之间。
在 Punch Through公司来说，客户通常是在已经实现了 BLE 串行策略后才来找此公司咨询的。而当有机会从头( from scratch)开始编写产品的通信协议时，通常会设计一种混合策略。
以下是我们设计混合 BLE 架构的一些经验法则：
-
从 BLE 串行策略开始，然后根据需要提取功能。
-
任何需要由中心快速访问的值都应具有外设始终保持更新的可读特性
-
日志或固件更新等批量后台传输应具有自己的特性，这样才不会阻塞(clog up)与用户体验相关的通信。
-
应将快速变化的状态信息分组，以便将这些信息视为单个时间点的快照。当系统需要来自多种传感器的数据来描述设备状态时，这一点非常有用。
-
对当前客户端无用的信息应通过不同的特性进行传输，或让客户端根据自己的兴趣打开或关闭信息。这样，客户端就能控制接收哪些信息。
-
对其他系统有价值的信息应通过标准蓝牙配置文件公开。(如电池电量battery level、温度等信息）
参考：
1，BLE SPP设计策略
Bluetooth Low Energy Serial: A Valid Design Strategy? | Punch Through