摘自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。
