BLE 技术（二）--- 协议栈架构与物理层设计 (Core_v5.2)

前言

前篇博文Bluetooth 协议栈设计与演进已经分别介绍了蓝牙协议的四大应用场景及对应的技术解决方案，为满足物联网设备的需求，蓝牙协议新增了室内精准定位技术、基于MESH 的大规模自组网技术和基于6LoWPAN 的IPv6 组网技术，逐渐在物联网无线技术中占稳短距离低速率无线通信的生态位，未来前景可期。

蓝牙技术联盟SIG 已经将重心放到BLE 低功耗协议上，为满足物联网设备需求新推出的技术方案也都是基于BLE 协议的，随着LE Audio 技术的发布，蓝牙设备的主要应用场景都可以在BLE 协议上承载，而不再依赖于BR/EDR 协议。由于BR/EDR 协议即将迟暮，且与LE 协议是相对独立的，二者并没有继承关系，后续将基于BLE 协议介绍蓝牙技术。

一、BLE System Architecture

对照上面的Bluetooth 协议结构图，屏蔽掉左边的BR/EDR Controller和右边的AMP Controller，只保留中间的LE Controller，将LE Controller 抽象为Physical Layer 和Logic Link Layer 两个层级（如果要进行LE Audio 开发，需要突出 Isochronous Adaptation Layer，本文就将其折叠进抽象的Link Layer了）。

LE Controller 与Host 之间有一个HCI 主机控制器接口层，该层定义了Host 与Controller 之间的通信接口规范。最早蓝牙是跟随手机发展的，蓝牙模块和手机处理器芯片都是一个独立的芯片，而且各自都有很多种，为了保证蓝牙模块与CPU 芯片之间通信的兼容性，SIG 就定义了一套统一的通信接口规范HCI，只要符合HCI 标准，不同的CPU 芯片与不同的蓝牙Controller 模块之间就能顺畅的通过HCI over UART/USB 接口完成通信（下图中间的方案，比如 CPU 芯片常采用Bluez 来实现Host 功能）。在低功耗低成本的物联网设备中，通常把Host 与Controller 放到同一个Soc 芯片上，这时物理的HCI 就没有存在的必要了，Host 与Controller 之间直接通过API 来交互（下图左边的方案，比如Nordic的蓝牙协议栈Softdevice 实现了整个蓝牙协议栈的功能）。下图右边的方案需要使用蓝牙芯片供应商提供的专有通信协议，通用性和兼容性受限。

Host 部分直接与Controller Link Layer 通信的是L2CAP (Logical Link Control an