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

 

前言：

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

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

　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　图1 蓝牙的无线链接模式

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

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

1、无线通讯

1.1 无线通讯原理

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

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

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

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

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

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

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

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

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

 1.2 电磁波谱

　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　图3 电磁波谱

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

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

　　　　　　

　　　　　　　　　　　　　　　　　　　　　图4 无线电频率频段划分

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

1.3 无线通讯协议

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

 

2、蓝牙通讯协议

　　通俗的讲，蓝牙协议栈上层封装下层传输过来的数据并提供接口供上层调用，上层只需使用下层提供的接口，不须要关心下层的具体实现细节。两个蓝牙设备之间每层使用相同的协议进行封装/解封装，最终在蓝牙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实现，在它们对应的层次上进行数据通讯，以完成所需功能。

 

3、低功耗蓝牙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全部参数长度，Parameter一、Parameter二、等等，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