以蓝牙为背景剖析无线通信原理以及协议栈

Posted 2020-08-17 basuny

 

前言：

　　基于传统点对点的架构，想要把家庭电脑和键盘、鼠标、耳机、麦克风、以及移动电话等等连接起来，可能还要考虑增加USB插口。

　　有没有一种通用的不需要用户干预的简便方法把各种电子设备连接在一起，而又不至于被线缆淹没呢？在WiFi之外，大家已经比较熟悉的“蓝牙”正是这样一种连接技术，它被设计为面向个人和家庭的无线式自动连接，其三大核心特点便是无线、低成本和自动化。

　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　图1 蓝牙的无线连接模式

　　可是“蓝牙”是怎么实现的上述所说的“连接”的呢？

　　下面我们从无线通信开始讲解，然后讲解蓝牙通信协议栈，最后讲解蓝牙低功耗中的广播通信。相信读完下面的介绍，便能理解蓝牙设备间是怎么实现通信的。

一、无线通信

1.1 无线通信原理

　　在发射端，发射机将已调制的高频震荡电流通过 “馈电设备” 输入发射天线，发射天线将高频电流转变为 无线电波—自由电磁波 向周围空间辐射。

在接收端通过接收天线将无线电波转化成高频电流，再经过馈电设备传输到接收机。

 　　　　　　　　　　　　　　　　　　　　　　　　图2 无线信号生成及传输过程

　　自由电磁波：是由同向且相互垂直的电场与磁场在空间中衍生发射的震荡粒子波，是以波动的形式传播的电磁场（电磁场是有内在联系、相互依存的电场和磁场的统一体的总称。随时间变化的电场产生磁场，随时间变化的磁场产生电场，两者互为因果，形成电磁场。电磁场可由变速运动的带电粒子引起，也可由强弱变化的电流引起，不论原因如何，电磁场总是以光 速向四周传播，形成电磁波）

　　馈电设备：被控制装置向控制点送电。

　　馈电设备可根据高频震荡电流的频率和形式 的不同，直接传输电流波或者电磁波。

　　电信号在接收端又是怎么转化成数字信号，供上层处理的呢？

　　这就是模数转换（AD），模拟信号是 有强弱变化的 电流, 智能终端里存储不了这种信号。所以要把这种电流的强弱变化通过另一种方式表达。于是就有了AD。它把电流强弱的变化翻译成了二进制代码存储在智能终端，也就是数字信号。 

　　同样的，可以通过数模转换（DA）把数字信号转化成模拟电信号，再由天线把电流转化成无线电磁波进行发送。

 1.2 电磁波谱

　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　图3 电磁波谱

　　无线频谱仅仅是所有电磁波谱的一个子集，例如，我们将频率为428570Ghz的电磁波识别为红色，本文中重点介绍的蓝牙频段范围是2.400-2.4835 GHz。

下表是 无线电 频率频段划分：

　　　　　　

　　　　　　　　　　　　　　　　　　　　　图4 无线电频率频段划分

　　人耳能够听见的音频信号的频率范围大约是20Hz-2OkHz。

1.3 无线通信协议

　　无线通信协议是为了完成了通信实体之间的通信而做的一些规则和约定的集合。因为没有实体，不是很好理解，可以类比下交通运输，路需要多宽，限速多少，道路标示怎么画，路两侧怎么防护，红绿灯的规则等等，都可以认为是"交通协议"，通信协议与其类似。

 

二、蓝牙通信协议

　　通俗的讲，蓝牙协议栈上层封装下层传输过来的数据并提供接口供上层调用，上层只需使用下层提供的接口，不需要关心下层的具体实现细节。两个蓝牙设备之间每层使用相同的协议进行封装/解封装，最终在蓝牙app层只关心的是传输数据中的有效信息，并不关心如CRC校验信息等。

　　蓝牙无线通信遵循IEEE的802.15标准，IEEE 802.15具有短距离、低功耗、低成本、小型网络及适用于个人操作空间的特点。由于蓝牙属于无线通信，则其通信介质是一定频率范围下的频带资源（Frequency Band），蓝牙的市场定位是个体和民用，因此使用免费的ISM频段（频率范围是2.400-2.4835 GHz）。（ISM:Industrial Scientific Medical，是由ITU，国际通信联盟无线电通信局定义的）

　　下面重点讲解蓝牙通信协议栈。协议栈如下图：

　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　图5 蓝牙协议栈

　　蓝牙协议分为四个层次：物理层（Physical Layer）、逻辑层（Logical Layer）、L2CAP Layer和应用层（APP Layer）。

物理层，负责提供数据传输的物理通道（通常称为信道）。通常情况下，一个通信系统中存在几种不同类型的信道，如控制信道、数据信道、语音信道等等。

逻辑层，在物理层的基础上，提供两个或多个设备之间, 和物理无关的逻辑传输通道（也称作逻辑链路）。

L2CAP层，L2CAP是逻辑链路控制和适配协议（Logical Link Control and Adaptation Protocol）的缩写，负责管理逻辑层提供的逻辑链路。基于该协议，不同Application可共享同一个逻辑链路。类似TCP/IP中端口（port）的概念。

APP层，理解蓝牙协议中的应用层，基于L2CAP提供的channel，实现各种各样的应用功能。Profile是蓝牙协议的特有概念，为了实现不同平台下的不同设备的互联互通，蓝牙协议不止规定了核心规范（称作Bluetooth core），也为各种不同的应用场景，定义了各种Application规范，这些应用层规范称作蓝牙profile。

　　在以上四个层次的基础上，蓝牙协议又将物理层和逻辑层划分了子层，分别是Physical Channel/Physical Links和Logical Transports/Logical Links，这一划分，相当使人崩溃，要多花费大量的脑细胞去理解它们，具体请参考下面的分析。

2.1 物理层

　　物理层负责提供数据传输的物理信道，又分为Physical Channel和Physical Links。

Physical Layer还需要定义RF(指物理信道)收发双方的一些特性，包括：

RF发射相关的特性（Transmitter Characteristics），包括发射功率（Transmission power、调制方式（Modulation），高斯频移键控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。

RF接收相关的特性（Receiver Characteristics），包括接收灵敏度等。

2.1.2 Physical Channel(物理信道)

　　分传统的蓝牙技术（BR）和 低功耗蓝牙技术（BLE）分别介绍Physical Channel

　　传统蓝牙技术BR这样定义信道：

1）ISM频带被分成79份，每一份带宽1MHz，称作RF Channel。在0 channel和78 channel之外设立guard band（保护带宽，Lower Guard Band为2MHz，Upper Guard Band为3.5MHz）。

2）采用跳频技术（hopping），也就是说，某一个物理信道，并不是固定的占用79个channel中的某一个，而是以一定的规律在跳动（该规律在技术上叫做"伪随机码"，就是"假"的随机码）。因此蓝牙的物理信道，也可以称作跳频信道（hopping channel）。

3）BR技术定义了5种物理信道（跳频信道），BR Basic Piconet Physical Channel、BR Adapted Piconet Physical Channel、BR Page Scan Physical Channel、BR Inquiry Scan Physical Channel和BR Synchronization Scan Channel。

4）BR Page Scan Physical Channel用于蓝牙设备的发现操作（discovery），即我们常用的搜索其它蓝牙设备（discover）以及被其它蓝牙设备搜索（discoverable）。

5）BR Inquiry Scan Physical Channel用于蓝牙设备的连接操作（connect），即我们常用的连接其它蓝牙设备（connect）以及被其它蓝牙设备连接（connectable）。

6）BR  Basic Piconet Physical Channel和BR  Adapted Piconet Physical Channel主要用在处于连接状态的蓝牙设备之间的通信。它们的区别是，BR  Adapted Piconet Physical Channel使用较少的RF跳频点。BR Basic Piconet Physical Channel使用全部79个跳频点，而BR Adapted Piconet Physical Channel是根据当前的信道情况使用79个跳频点中的子集，但是跳频数目也不能少于20个。这个主要是因为蓝牙使用ISM频段，当蓝牙和WIFI共存的时候，部分跳频点被WIFI设备占用而使得蓝牙设备在这些跳频点上的通信总是失败，因此，需要避过那些WIFI设备占用的频点。

7）BR Synchronization Scan Channel可用于无连接的广播通信，后续文章会详细介绍。

8）同一时刻，BT 设备只能在其中一个物理信道上通信，为了支持多个并行的操作，蓝牙系统采用时分方式，即不同的时间点采用不同的信道。

　　BLE低功耗蓝牙技术这样定义信道：

1）ISM内整个频带分为40份，每份的带宽为2MHz。在0 channel和39 channel之外设立guard band（保护带宽，Lower Guard Band为2MHz，Upper Guard Band为3.5MHz）。

2）LE技术定义了2种物理信道，LE Piconet channel和LE Advertisement Broadcast Channel。

3）LE Piconet Channel用在处于连接状态的蓝牙设备之间的通信，和BR一样，采用调频技术。和BR不一样的地方是，只会在40个频率channel中的37个上面跳频。

4）LE Advertisement Broadcast Channel用于在设备间进行无连接的广播通信，这些广播通信可用于蓝牙的设备的发现、连接（和BR/EDR类似）操作，也可用于无连接的数据传输。

5）和BR一样，同一时刻，BT 设备只能在其中一个物理信道上通信，为了支持多个并行的操作，蓝牙系统采用时分方式，即不同的时间点采用不同的信道。

AMP是为高速数据传输设计的技术，也是传统蓝牙技术的一种，其物理层规范直接采用802.11（WIFI）的PHY规范，主要有如下特点：AMP物理信道只有一种，即AMP Physical Channel，主要用于已连接设备之间的数据通信，和BR技术中的BR Adapted Piconet Physical Channel位于一个级别，可以互相切换使用。

2.1.2 Physical Links

　　物理链路层，是对Physical Channel物理信道（主要是BR技术中的Basic Piconet Physical Channel和Adapted Piconet Physical Channel）的进一步封装。

2.2 逻辑层

　　逻辑层的主要功能，是在已连接（LE Advertisement Broadcast可以看做一类特殊的连接）的蓝牙设备之间，基于物理链路，建立逻辑信道。所谓的逻辑信道，和城市道路上的车道类似：

一条城市道路可以看做一个物理链路（我们只考虑一个方向即可），该物理链路根据行车用途，可以划分为多个逻辑信道，如直行车道、右转车道、左转车道、掉头车道、快速车道、慢速车道等等。

和车道类似，蓝牙逻辑信道的划分依据是传输类型，主要包括下面3类（即Logical Link）：

1）用于管理底层物理链路的控制类传输。

2）传输用户数据的用户类传输，包括。

3）其它比较特殊的传输类型。

　　由于Physical Channel是不可靠的，任何数据传输都可能由于干扰等问题而损毁、丢失，这对有些应用来说，是接受不了的。因此Link Layer提供了校验、重传等机制，确保数据传输的可靠性；Link Layer还提供数据过滤机制，主要针对广播通道，因为随着通信设备的增多，空中的广播数据将会呈几何级的增长，为了避免资源的浪费（特别是BLE Host），有必要在Link Layer过滤掉一些数据包，例如根据蓝牙地址，过滤掉不是给自己的packet。

2.3 L2CAP Channels

　　L2CAP是Logical Link Control and Adaptation Protocol（逻辑链路控制和适配协议）的缩写，它介于应用程序和Link Layer层之间的协议：

对下，它在用户类Logical Link的基础上，抽象出和具体技术无关的数据传输通道（包括单播和广播两类），至此用户就不再需要关心繁杂的蓝牙技术细节。

对上，它以L2CAP channel endpoints的概念（类似TCP/IP中的端口），为具体的应用程序（profile）提供独立的数据传输通道（指的是逻辑通道）。

　　它提供的功能主要包括：通道的多路复用，对上层应用数据的分割和重组，生成协议数据单元（PDUs），以满足用户数据传输对延时的要求，并便于后续的重传、流控等机制的实现。

2.4 Profiles

　　profile是蓝牙Application的代指，也可以翻译为服务，为了实现不同平台下的不同设备的互联互通，蓝牙协议为各种可能的、有通用意义的应用场景，都制定的了规范，如SPP、HSP、HFP、FTP、IPv6/6LoWPAN等等。

　　Profiles基于L2CAP提供的L2CAP channel endpoints实现，在它们对应的层次上进行数据通信，以完成所需功能。

 

三、低功耗蓝牙BLE广播通信原理

　　传统蓝牙BR虽然在协议底层有提及多播和广播的概念，但在上层的应用场景中，更侧重于点对点的通信，几乎不存在广播相应的应用。而低功耗蓝牙BLE相比传统蓝牙，最大的突破就是加大了对广播通信（Advertising）的支持和利用。

3.1 BLE广播通信使用场景

1）单一方向的、无连接的数据通信，数据发送方在广播信道上广播，接收方扫描、接收数据。

2）连接的建立。

3.2 协议层次

　　BLE广播通信相关的协议层次：

GAP --> HCI --> Link Layer

　　LinkLayer(LL)  位于最底层，负责广播通信有关功能的定义和实现，包括物理通道的选择、相关的链路状态的定义、PDU的定义、设备过滤（Device Filtering）机制的实现等。

　　HCI负责将LL提供的所有功能，以Command/Event的形式抽象出来，供上层使用。

　　GAP负责从应用程序的角度，抽象并封装LL提供的功能，以便让应用以比较傻瓜的方式进行广播通信。

3.3 Link Layer

3.3.1 状态定义

　　从LL层看，参与广播通信的BLE设备，可有三种状态：　

Advertising，数据发送方，周期性的发送广播数据；

Scanning，数据接收方，扫描、接收广播数据；

Initiating，连接发起方，扫描带有“可连接”标志的广播数据，一旦发现，则发起连接请求（都是由Link Layer自动完成，不需要上层软件参与）。

3.3.2 PDU

　 处于不同状态的BLE设备可以发送不同类型的PDU数据。

PDU格式：（具体每个字段的意义如图所标）

　　

　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　图6 pdu格式

PDU类型：

　　　　　　　　　　　　

　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　图7 PDU类型

举例：

1）如果只需要定时传输一些简单的数据（如某一个温度节点的温度信息），后续不需要建立连接，则可以使用ADV_NONCONN_IND。广播者只需要周期性的广播该类型的PDU即可，接收者按照自己的策略扫描、接收，二者不需要任何额外的数据交互。

2）如果除了广播数据之外，还有一些额外的数据需要传输，由于种种原因，如广播数据的长度限制、私密要求等，可以使用ADV_SCAN_IND。广播者在周期性广播的同时，会监听SCAN_REQ请求。接收者在接收到广播数据之后，可以通过SCAN_REQ PDU，请求更多的数据。

3）如果后续需要建立点对点的连接，则可使用ADV_IND。广播者在周期性广播的同时，会监听CONNECT_REQ请求。接收者在接收到广播数据之后，可以通过CONNECT_REQ PDU，请求建立连接。

4）通过ADV_IND/CONNECT_REQ的组合建立连接，花费的时间比较长。如果双方不关心广播数据，而只是想快速建立连接，恰好如果连接发起者又知道对方（广播者）的蓝牙地址（如通过扫码的方式获取），则可以通过ADV_DIRECT_IND/CONNECT_REQ的方式。

3.3.3 Advertising状态

　　BLE使用40个RF Channel（前文有述）中的3个作为广播信道，信道频段信息等如下：

　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　图8 广播信道

　　BLE设备处于Advertising状态的目的，就是要广播数据。并且，根据应用场景的不同，可在3个channel上广播4种类型的数据。

　　BLE协议对广播通信的期望，是非常明确的，不在乎速率、只在乎功耗。对于连接来说，如果事先不知道连接发起者的设备地址，则最快的连接速度可能是20ms。如果事先知道地址，则可能在3.75ms内建立连接。由此可以看出，BLE的连接建立时间，比传统蓝牙少了很多，这也是BLE设备之间不需要保持连接的原因。

3.3.4 Scanning状态

　　scanWindow指示一次扫描的时间，scanInterval指示两次扫描之间的间隔。如果这两个参数的值相同，表示连续不停地扫描。Scanning的扫描就是由　　　scanWindow和scanInterval两个参数决定的。

　　BLE协议规定，scanWindow和scanInterval最大不能超过10.24s，并且scanWindow不能大于scanInterval。

　　Passive Scanning和Active Scanning

　　Passive Scanning称作消极的扫描，是因为这种扫描模式下，BLE设备只听不问，也就是说，只接收ADV_DIRECT_IND、ADV_IND、ADV_SCAN_IND、ADV_NONCONN_IND等类型的PDU，并不发送SCAN_REQ。而Active Scanning，不只认真听讲，还勤于发问（SCAN_REQ），并接收后续的 SCAN_RSP。

　　这两种Scanning的最终结果，就是把接收到的数据（包括Advertiser地址、Advertiser数据等），反馈给上层。

3.3.5 Initiating状态

　　Initiating状态和Scanning状态类似，只不过它的关注点不一样：它不关心广播数据，只关心ADV_DIRECT_IND和ADV_IND两类消息，并在符合条件的时候，发出CONNECT_REQ，请求建立连接。

3.3.6 设备过滤机制

　　如果多个BLE设备同时发广播，Scanner怎么过滤自己不想要的广播，这时候设备过滤机制的白名单就上场了。LL层的白名单针对PDU三种类型（Advertising, Scanning, Initiating）分别有一个白名单，这个白名单可以设置。　　　　　　　　

 3.4 HCI

　　HCI层将Link Layer层提供的功能封装成Command和Event。

3.4.1 HCI Command/Event模式

　　HCI Command格式：（参考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]”）

　　　　　　　　　　　

　　其中OCF和OGF组成16bit的操作码，Parameter Total Length，指示该Command所有参数长度，Parameter1、Parameter2、等等，16 bits的参数，由具体的Command决定。

　　HCI Event格式：

　　　　　　　　　

3.4.2 广播通信相关的HCI Command

　　BLE相关的HCI Comman使用的HCI Command的OGF都是0x08。

Advertising状态有关的命令

1）HCI_LE_Set_Advertising_Parameters

设置广播参数，包括Advertising Interval、Advertising Type、本机的地址类型、对端设备的地址类型和地址、所使用的物理Channel的map、Advertising白名单等。

2）HCI_LE_Set_Advertising_Data

设置广播数据，OCF为0x0008，Command参数的格式如下：

例如，下划线依次代表OGF、OCF、Advertising Data Length、Advertising Data。

3）HCI_LE_Set_Scan_Response_Data

设置Scan请求时的应答数据，OCF为0x0009，格式和HCI_LE_Set_Advertising_Data一样。

4）HCI_LE_Set_Advertise_Enable

控制Advertising的使能与否，ICF为0x000a，命令参数包括一个8 bits的“Advertising Enable”，如下：

hcitool -i hci0 cmd 0x08 0x000A 01

Scanning状态有关的命令

1）HCI_LE_Set_Scan_Parameters

设置scan参数，包括Scan Type、Scan Interval、Scan Window、本机的地址类型、Scanning白名单等。

2）HCI_LE_Set_Scan_Enable

Scan动作的开关，其数据格式和HCI_LE_Set_Advertise_Enable一致。

Initiating状态有关的命令

1）HCI_LE_Create_Connection

建立连接，可指定Sca Interval、Scan Window、Initiator Filter Policy、Peer Address Type、Peer Address、Own Address Type等Initiating有关的参数，也可以指定连接相关的参数。

2）HCI_LE_Create_Connection_Cancel

取消连接。

白名单有关的命令

包括：

HCI_LE_Read_White_List_Size，获取BLE Controller的白名单大小；

HCI_LE_Clear_White_List，清空白名单；

HCI_LE_Add_Device_To_White_List，将设备添加到白名单；

HCI_LE_Remove_Device_From_White_List，将设备从白名单移除；

3.5 GAP

3.5.1 GAP定义

　　对于广播通信，GAP主要的工作是Link Layer的“协议语言”，如Advertising、Scanning、Initiating等，转换为更为直观的“人类语言”以及定义扫描数据和广播数据的统一规范。

　　GAP层把Link Layer层的状态进行了又一次抽象，分别如下：

　　1）广播模式以及解析过程。GAP为该模式下的设备定义了两个角色（GAP role）：Broadcaster（具有“Broadcast mode”能力）和Observer（具有“observation procedure”能力。

　　2）发现模式以及对应的发现过程。GAP为该模式下的设备定义了两个角色：Peripheral（被发现的设备）和Central（主动发现别人的设备）。不同的设备可以选择具有以下能力：

Non-Discoverable mode，不可被发现，设备不会广播任何数据；Limited Discoverable mode，可被发现（有限的），指设备只会在有限的一段时间内，广播数据；General Discoverable mode，可被发现（通用的）；Limited Discovery procedure ，可执行有限的发现操作，可发现处于“Limited Discoverable mode”的设备；General Discovery procedure ，可执行通用的发现操作，可发现处于“Limited Discoverable mode”和“General Discoverable mode”的设备；Name Discovery procedure，可进行Name的发现操作。如果通过Scanning操作没有得到广播设备的名称，使用该过程，可以在建立连接之后，再获取对方的名字。

　　3）连接模式以及对应的连接过程。所有四种角色的设备，Peripheral、Central、Broadcaster和Observer都可能涉及连接模式。

设备可以选择连接有关的模式：

Non-connectable mode，不可被连接的模式；Directed connectable mode，可被指定的设备连接；Undirected connectable mode，可被连接（不指定设备）；Auto connection establishment procedure，可自动连接模式；General connection establishment procedure，通用的连接过程等。

3.5.2 广播数据格式

　　BLE协议31个bytes的广播数据和扫描应答数据的格式如下：

　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　图9 广播数据和扫描应答数据的格式

　　广播数据/扫描应答数据一个个的AD Structure组成，未满31bytes的数据由0填充；每个ADStructure有1byte的长度信息（Data的长度），和剩余的Data组成。

　　Data由AD Type和AD Data组成。其中AD Type可以指定Service UUID，设备支持哪些profile；Local Name，设备的名称； Flags，设备的GAP发现连接能力等。结合上面的例子，再分析下：

　　　　　　

　　02 01 06，是一个AD Structure：Data的长度是02；Data是01 06；AD Type是01（Flags）；AD Data是06，表明支持General Discoverable Mode可被发现、不支持BR。

　　03 03 aa fe，是一个AD Structure：Data的长度是03；Data是03 aa fe；AD Type是03（16 bits的Service UUID）；AD Data是aa fe，是Eddystone profile的Service UUID。

　　17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是一个AD Structure：Data的长度是17（23bytes）；Data是16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00；AD Type是16（Service Data）；AD Data是aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是Eddystone profile具体的Service Data。

 

总结

　　读罢全文，如果还有“似懂非懂、欲说还休”的感觉，太正常了，毕竟蓝牙协议是一个历史悠久又比较庞大的协议，本文当一个学习笔记吧，以后遇到相关的问题，来这篇文章查查应该就可以了。 

 

 

参考文档：

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

CSS(Core Specification Supplement)

https://github.com/google/eddystone/blob/master/protocol-specification.md

IPSP SPEC, 1.0, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307

IETF RFC7668, IPv6 over BLUETOOTH(R) Low Energy, https://datatracker.ietf.org/doc/rfc7668/?include_text=1

LE_PSM_IPSP, https://www.bluetooth.com/specifications/assigned-numbers/logical-link-control

http://embedded-computing.com/articles/bluetooth-smart-and-zigbee-if-you-cant-beat-them-join-them/

https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

https://tools.ietf.org/html/rfc4944

www.wowotech.net

http://wenku.baidu.com/view/e8f2f546336c1eb91a375d80