蓝牙core系统体系结构
摘自core spec v4.1（只讨论BR/EDR）
Channel manager
负责创建，管理和销毁用于传输服务协议和用户数据流的 L2CAP 频道。 Channel manager 使用 L2CAP 协议来同远端的 channel manager 交互，来创建 L2CAP 频道，连接它们的端点到合适的实体。 Channel manager 同自己本地的 link manager 或者 AMP PAL 来创建新的逻辑链接（如果需要），并且配置这些链接来提供数据传输服务所需要的质量。
L2CAP resource manager
L2CAP resource mangager 负责管理到 baseband 的 PDU 分片传输的排序和 channel 之间相关的调度，确保特定QoS 约定的 L2CAP channel 不会因为 controller 资源衰竭而被拒绝访问 physical channel 。因为蓝牙架构模型并不假定 controller 有无限的缓冲能力，也不假定 HCI 是一个有无限带宽的管道，所以 L2CAP resource manager 是需要的。
AMP Manager Protocol
AMP manager 使用 L2CAP 来同对端的 AMP manager 通讯。出于 AMP 控制目的， AMP manager 也直接使用AMP PAL 的接口。 AMP manager 负责发现（ discovery ）远端的 AMP(s) ，并确定它们的有效性。它搜集远端的AMP(s) 信息。这些信息用来建立和管理 AMP 物理链接。 AMP manager 使用专用的 L2CAP 信号渠道 (dedicated L2CAP signaling channel) 来同远端的 AMP manager(s) 通讯。
Device Manager
Device manager 是 baseband 的一个功能模块，它控制了蓝牙设备的基本行为。它负责蓝牙系统中未同数据传输直接相关的所有操作，比如查询附近是否存在蓝牙设备，连接到其它蓝牙设备，或者让本地蓝牙设备可以被其它设备发现或者连接。
Device manager 为了实现这些同能，要求访问 baseband resource controller 的传输介质。
Device manager 也通过一系列 HCI 命令来控制本地设备行为，比如管理设备的本地名，存储 link keys 和其它功能。
Link Manager
Link Manager 负责逻辑链路（如果需要，也包括逻辑传输）的创建，修改和释放，以及设备间同物理链接相关的参数的更新。 Link manager 通过同对端蓝牙设备的 link manager 使用 LMP （ Link Management protocl ）通信来实现这些功能。
LM 协议允许设备间在需要时逻辑链路和逻辑传输的创建，以及对链路和传输特定的一般控制，比如在逻辑传输的时候是否加密，物理链接上传输功率的修改，和逻辑链路上 QoS 设置的调整。
Baseband Resource Manager
Baseband resource manager 负责对无线介质的所有访问。它有两个功能。核心功能是一个调度器，负责给通过协商获取到访问约定的实体分配占用物理信道的时间。另外一个功能是同这些实体协商访问约定。访问约定是为了提供用户应用程序一个预期的性能来传输所要求的 QoS 的一个承诺。
访问约定和调度功能必须考虑到要求使用 BR/EDR 控制系统的所有行为。包括已连接设备在逻辑链路和逻辑传输上的正常数据交互，以及使用无线介质来携带查询，建立链接，可以被发现和被连接等。
在某些情况下，逻辑链路的调度会导致从之前使用的物理信道切换到不同的物理信道。
Link Controller
Link controller 负责从同物理信道，逻辑传输和逻辑链路相关的数据负载和参数中编码和解码蓝牙包。
Link controller 携带 link control 信号（同 resource manager 的调度功能紧密结合），用来实现流控，确认和传输请求的信号）。这些信号的解释是同 baseband packet 相关的逻辑传输的一个特性。 Link control 信号的解释和控制同 resource manager 的调度相关。
RF
RF 模块负责传输和接收物理信道的数据。 Baseband 和 RF 模块之间的控制路径允许 baseband 模块控制 RF 模块的时间 (timing) 和频段。 RF 模块将从物理信道和 baseband 获取，或者要转换到物理信道和 baseband 的数据流转换成要求的格式。
AMP HCI
AMP HCI 是 AMP controller 和 Host(L2CAP 和 AMP manager) 之间的的逻辑接口。当 Host 和 AMP Controller(s)在物理上是分开的， HCI 是可选的层。 AMP 的支持要求额外的 HCI 命令和事件。这些新的命令和事件同 AMP 物理和逻辑链路管理 ,QoS, 流控相关。
每个 AMP controller 有一个 HCI 的逻辑实例，每一个 BR/EDR 也有一个 HCI 的逻辑实例。当多个 controller 共存于同一个简单的物理单元的时候，物理 HCI 传输层管理着在同一个物理传输总线上的多个 Controller 的多路复用。
AMP PAL
AMP PAL 是 AMP MAC 和 Host(L2CAP 和 AMP manager) 之间的 AMP 接口层。它将来自 Host 的命令转换成指定的 MAC 服务源语，将服务源语转换成命令，并将来自 AMP MAC 的源语转换成 Host 可以理解的事件。 AMP PAL提供 AMP 信道管理，根据指定流程规定的数据交互，电源效率的支持。
PAL 的架构图
PAL 和底下的 MAC/PHY 的性能由 AMP manager 协议通过 AMP_Info 和 AMP_Assoc 结构交换。 AMP_Info 包含基本的 PAL 性能，比如可用带宽，最大 PDU 大小， PAL 吸能， AMP_Assoc 的长度和 flush timeout 信息。AMP_Assoc 的内容取决于 PAL ，并同底下的 MAC/PHY 相关。
AMP MAC
IEEE802 参考层模型中的 MAC 层。它提供的寻址，控制和访问信道的机制。
AMP PHY
AMP 物理层
从图中我们就可以看出BT的inquiry和page以及connect data等。
inquiry阶段：
图中可以看出user进行inquiry的时候会直接command到HCI层然后进入到controller。（图中最左边那条线，通过抓包已经验证，不然会抓到L2CAP以上层的packet）。同时回复也是通过这条线路。然后controller内部进行LMP管理搜索到周围的BT。
page阶段：
因为在inquiry阶段已经搜索到的BT，所以我们这里可以点击一个设备进行page连接，这里我们还是从最左边那条线下来，因为此时都是一些command和event。ACL逻辑传输还没建立起来。当建立完成后（在这之前会有很多LMP端的身份验证等步骤），那么此时一条最基本的ACL就建立了（注意：一个maste跟一个slave之间只能有一条ACL）。之后两端就会返回一个connection handle给HCI层（该handle已经与对方的BD_ADDR进行了绑定）。所以以后发送数据给该handle就可以了。
connection阶段：
建立完毕后，我们还是不能发送数据，因为BT profile上层也需要建立相应的服务（比如发数据还是传文件）。这些都是依靠L2CAP层，所以我们需要建立L2CAP层，L2CAP利用建立起来的ACL传输自己command申请建立一条ACL-U的逻辑链路，此时会分配自己的CID（对方也是如此），且该CID与ACL的handle绑定了。这里我们的L2CAP就建立一条逻辑链路。同理，更上层都是如此。
这里有几个概念很重要，困惑了我许久。关于L2CAP信道，逻辑链路，逻辑传输，物理链路，物理信道。
先看图：
逻辑传输有五种（ACL，SCO,eSCO，ASB,PSB）
逻辑链路（ACL-C，ACL-U,SCO,eSCO,LC）
物理信道指基本跳频，自适应跳频，page跳频，inquiry跳频。
我们从图中也可以看出inquiry阶段：物理信道是inquiry跳频
进入page阶段物理信道是page跳频。
等建立完毕之后就进入了自适应跳频信道，此时我们的逻辑传输ACL也建立好了。但还没有逻辑链路。等我们L2CAP想建立的时候，首先先建立逻辑链路。比如ACL-U。
