低功耗蓝牙开发技术概述（三）——主机

首先来看看低功耗蓝牙的体系架构图，其实在上面的章节中已经出现过，这里再次把它搬出来看看

以下的所有内容都是主机那层的内容

1、逻辑链路控制和适配协议

和经典蓝牙完全不同，低功耗蓝牙的一个基本概念在于无连接模式。用户只在需要发送数据的时候才建立莲接，其他时候设备可以长期处于断开连接状态。为了实现该功能，无连接模式必须扩展到L2CAP层，并且只能使用固定信道。在低功耗蓝牙设计之初并未选择L2CAP，而是使用了另一个称为协议适配层（Protocol Adaptation Layer，PAL）的设计。PAL仅支持两种数据包：高层协议信令数据包以及自身的信令数据包。PAL不支持分割或重组，也没有区分不同协议的功能。协议设计的一个基本原则是每一层协议都是独立的。在经典蓝牙中，面向连接信道可以把某对单独的应用数据与其他信道的数据相分离。举个例子，虽然所有的面向连接信道都能添加额外的数据完整性检测，但它们可能有不同的流规范，或者隶属于流信道而非尽力交付信道。面向连接信遭非常适合那些复杂的、多种数据同时传输的系统。

（1）、L2CAP信道

L2CAP有个很简单的概念——信道。毕竟L2CAP是一种复用层，有多个信道也不足为怪。信道是指一个数据包序列，连接两个设备上的一对服务。在两个设备间允许同时启用多条信道。低功耗蓝牙只支持固定信道。固定信道指的是两个设备一建立连接就已经存在的、没有任何配置参数的信道。

（2）、L2CAP数据包结构

每个L2CAP数据包的净荷前端都包含一个32位比特报头。假设使用分割和重组，那么数据包的长度信息必须包含在报头中，以便判断数据包的结束。使用分割和重组机制需要为每个通过HCI接口的数据包打上标记，分为开始数据包或延续数据包。不过，这里没有定义怎样标记当前数据包的最后一个片段。选意味着，判断当前数据包唯一方法是发送一个新的数据包，或者将数据包的长度信息放在开始数据包中。如下图所示，报头包括2字节的长度字段和2字节的信道标识符。长度字段表示报头后的信息载荷字节数。在经典蓝牙中，信息载荷还可以包含额外的报头和信息，但在低功耗蓝牙的L2CAP层中并没有其他有意义的信息结构。

（3）、低功耗信令信道

每个低功耗信令信道的数据包均含有一操作码，随后为各种参数。低功耗信令信道支持的命令操作码如下：

  （*）命令拒绝（Command Reject）

  （*）连接参数更新请求（Connection Parameter Update Request）

  （*）连接参数更新响应（Connection Parameter Update Response】

在低功耗蓝牙中，由于只定义一种请求命令粪型，并且该请求命令仅用于没有其他请求发送的情况，标识符的逻辑相对简单。L2CAP命令数据包如下图所示

命令拒绝：用于拒绝设备收到的不支持的信息包。该命令与经典蓝牙中的命令拒绝完全一样。它包含一个原因代码以及相关信息。其中的原因代码可以是“命令不理解”或“信令MTU溢出”。连接参数更新请求和响应：可以让从设备更新链路层的连接参数，这些参数包括连接事件间隔（从设备希望主设备允许从设备发送数据包的频率）、从设备延迟（从设备能够忽略主设备的连接事件的最大值）以及监控超时。连接参数更新请求命令仅用于从设备向主设备发送，这是由于主设备随时都能启动链路层连接参数更新控制（ConnectionParameter Update Control）规程。如果该命令由主设备发送，从设备会将其视为一个错误，并返回带有“命令不理解”原因代码的“命令拒绝”命令。

2、属性

在低功耗蓝牙的设计之初，使用什么样的协议就成为了一个难题。协议应当十分简单，因为任何的复杂性都会增加额外的成本和所需的存储空间；同时，协议的数量要越少越好。由此，有人认为使用一种单一的、普适的协议在该技术的起步阶段是最佳的选择。不过这个想法并没有完全实现。低功耗蓝牙最后使用了三种协议：逻辑链路控制和适配协议(L2CAP)，安全管理协议(SM)和属性协议(AP)。精简协议：所有的计算乃至世上的大部分事物都围绕着协议运转。大多数的行为有其自身的协议，例如：载入网页用到了超文本传输协议(HTTP)；传输文件用到了文件传输协议(FTP)；安全的登陆另一台电脑，用到了安全外壳协议( SSH)。每一种协议都专攻于它自己的应用场合，试想要是用HTTP协议传输大量的文件，或是用FTP拇议登录电脑，那显然是欠缺效率的。低功耗蓝牙技术和成堆的因特网协议的最大区别在于，低功耗蓝牙技术并不试图传输多样化的数据类型。考虑到不会用来传输大批量的数据或是流媒体音乐，为其开发一种能够处理有限的几种数据类型的协议就可以。这种协议被称为属性协议，是整个蓝牙技术的基石和构造组件。只有理解了属性协议才能理解低功耗蓝牙技术。

数据与状态：还有一个需要理解的概念是：数据( data)与状态（state）这两者有着显著的差别。数据是一个值，它反映了某种客观性质，比如某种测量的结果、读数。数据可以是温度计涮出的房间温度，也可以是供暖系统测出的室内温度；它们都可以被不同的设备测量出来。而状态则反映了某个设备的当前状况或处境：它在做什么、是怎么运作的。设备的状态只有它自己知道，并靠自身维持。温控器测量室温，温度的度数则反映了房间温度的状态。几种常见的状态：低功耗蓝牙用到了三种不同种类的状态类型：外部状态、内部状态与抽象状态。物理测量值反映了物理传感器或者类似接口的当前状态+让我们设想一个浴室里的体重计。

状态机：有趣的是，有限状态机可以明确地使用属性协议和可公开的状态来表示。状态机反映了设备的内部状态，并且有一个或多个外部的辅人接口。这些外部辅人为瞬时命令，根据其他状态信息或行为来改变状态机的状态。这是一个抽象状态，或称为控制点。

服务和规范：从经典蓝牙到低功耗蓝牙，最有趣的转变是服务和规范的体系结构。经典蓝牙里的规范和协议大多定义的是行为与交互指南，它们极其复杂，糅合了许许多多不同的概念。其中，一个最大的问题是这些规范倪定义了两种设备类型，位于链路的两端，再对各自的行为分别定义。粗略地看来，这种做法似乎很有必要：好比体有一部手机和车载（免提）套件，我们必须基于具体应用为其定义各自的工作方式以及交互方式。不幸的是，这也造成了一些麻烦。首当其冲的问题在于，现有的规范对网络中的设备自身的行为定义不够明确。换言之，即便看起来两个设备都定义了各自的行为，但有时候设备自身到底应该怎么做其实并不清楚。低功耗蓝牙使用了一种截然不同的方法来解决上述问题。首先，它采用了纯粹的“客户端一服务器”的结构，针对不同的用例对服务器和客户端的行为单独进行描述。服务器的行为在服务器规格书中定义，而用户的行为在另一规范说明中定义。通过一个属性数据库，服务器规格书定义了需要公开的状态以及通过属性可以实现的行为。将服务器和客户端区分开的最大的好处是，服务器的行为将是预先定义并可知的。它只会做服务说明中定义的“该做”的事情，不会关心客户端将怎样去使用它。这意味着服务可以独立执行单元测试，而与客户端无关；任何客户端可以在必要的时候使用这些服务。举个例子，假设有一种提供时间的服务，某个客户端可用其获取当前时间；另一个客户端周期性地读取当前时间来判断自身的时钟漂移；其他客户端还可以请求其使用GPS接收机以便获得最精确的授时。你瞧，这个时间服务并不关心客户端在做什么，它仅仅提供该服务罢了。

（1）、属性

要理解属性协议，首先要理解什么是属性。宽泛地讲，属性是一条带有标签的、可以被寻址的数据。在后续的章节里，我们将深入介绍属性的含义以及在实际操作中的使用属性概述：如下图所示，属性由三种数值组成：属性句柄、属性类型和属性值。

属性句柄：一台设备可以有许多的属性，例如温度传感器可能包含温度属性、设备名称属性和电池电量属性。表面看来，通过属性类型似乎足以判别某种属性：比如使用温度属性来获取温度，通过设备名称属性来获取设备名等。但是，如果设备包含了两种温度属性，比如一个室内温度传感器加上室外温度传感器，情况会变得怎样。这时你便无法直接读取温度传感器，而必须读取第一个或第二个温度属性。考虑到可能有任意多个温度传感器，问题将变得更加复杂。为了解决这个同题，我们使用了一个16位的地址，也就是属性句柄。有效的句柄范围从Ox0001 -OxFFFF。Ox0000为无效句柄，不能用于寻址属性。你可以根据自己在软硬件或嵌入式方面的背景，把句柄相应地想象为内存地址、端口号、属性值对应的硬件寄存器地址。属性类型：可以被公开的数据有许许多多的类型：温度、压强、体积、距离、功率、时间、充电状态、开关状态、状态机的状态等。所公开的数据的种类称作属性类型。为了区分如此多的数据类型，一串128位的数字被用来标识属性的类型。这个唯一的标识码就叫做通用唯一识别码（UUID） 128位的UUID相当长，设备间为了识别数据的类型需要发送长达16个字节的数据。为了提高传输效率，蓝牙技术联盟( SIG)定义了一十称为“蓝牙UUID基数”的128位通用唯一识别码，结合一个较短的16位数使用。二者仍然遵循通用唯一识别码的分配规则，只不过在设备间传输常用的UUID时，只发送较短的16位版本，接收方收到后补上蓝牙UUID基数即可。

蓝牙UUID基数如下：

00000000—0000—1000—8000—00805F9B34FB

例如要发送的16位识别码位0X2A01，完整的128位UUID便是：

00002A01—0000—1000—8000—00805F9B34FB

谈到16位的UUID，通常不直接使用数值，而是冠以一个名称并加上书名号

 0x1800 - 0x26FF用作服务类通用唯一识别码

 0x2700 - 0x27FF用于标识计量单位

 0x2800 - 0x28FF用于区分属性类型

 0x2900 - 0x29FF用作特性描述

 0x2A00- 0x7FFF用于区分特性类型

属性值：属性值用于表示设备公开的状态信息。属性值的长度可以从。字节到最长512字节，但某些类型的属性值的长度则是固定的。属性值对属性协议来说并不重要，但它对于上层，包括通用属性规范和在其之上的服务与规范来说有着相当重要的意义。

（*）服务通用唯一识别码：每一种服务都能用一个UUID来辨认。它既可以是16位的UUID，也可以是完整的128位的UUID。在I6位的UUID申已经分配了3840种服务，而128

位的UUID可以容纳近乎无穷的专有服务。

（*）单位：许多公开的数值反映了某种传感器测量的物理量，因此有必要为所有可能的数值定义相关单位的UUID。这些单位由国际计量局制定，亦称国际单位制(SI)。这使得

低功耗蓝牙传感器采集的数值可供其他同样采用国际单位制的系统所使用。要注意国际单位制用的是公制单位，人们还定义了英制单位的UUID

（*）性类型：用于识别属性类型的UUID中包含了一些最基本的属性类型，一般用于通用属性规范，而非具体的服务。这些属性类型包括：

  a.首要服务

  b.次要服务

  c.包含

  d.特性

（*）特性描述符：一些服务公开的数据包含了额外的信息。这种额外的信息便被冠以特性描述符。

（*）特性类型：特性类型是16位UUID中使用最多的一组。服务为公开的每一类数值都分配了一个“特性类型”UUID。客户端从而能够发现服务器提供的所有不同类型的数据。

（*）数据库、服务器和客户端：一组属性的集合称作数据库。数据库可以很小很简单，小至仅包含六种属性．也可以很大很复杂。属性数据库的复杂度不在于其层次，而在于服务和规范如何使用这些属性。

（*）属性许可：一些属性服务器上的属性含有可读或可写信息。为了提供这类访问限制，数据库中的每一个属性都含有一个许可。许可自身可以分为三种类型：使用许可、认证许可和授权许可。使用许可央定了某一属性所能执行的请求的类型。

（*）属性数据库：

属性句柄	属性类型	属性值
0x0001	首要服务	GAP服务
0x0002	特性	设备名
0x0003	设备名	“接近标鉴”
0x0004	特性	外观
0x0005	外观	标签
0x0006	首要服务	OATT服务
0x0007	首要服务	发射功率服务
0x0008	特性	发射功率
0x0009	发射功率	-4dBm
0x000A	首要服务	立即报警服务
0x000B	特性	报警级别
0x000C	报警级别
0x000D	首要服务	连接丢失服务
0x000E	特性	报警级别
0x000F	报警级别	电量服务
0x0010	首要服务	电池余量
0x0011	特性
0x0012	电池余量	75%
0x0013	特性表达格式	8位无符号整形．0，百分比
0x0014	特性	电池余量状态
0x0015	电池余量状态	75%放电中
0x0016	客户端特性配置	0x0001

（*）接入属性：客户端可以通过使用下列任意一种消息类型来访问属性数据库的各个属性：

  寻找请求、读取请求、写入请求、 写人命令、通知、指示

  客户端先使用“寻找请求”来寻找属性数据库中的属性，随后才能使用效率更高的基于句柄的请求。发送读取请求用以读取某个属性值。要确定读取的具体属性，应指定一个或多个属性句柄或者句柄范围，以及属性的类型。 发送写入请求用以写入某个属性值。该请求常常会用到一个属性句柄和要写人的数值。也可以事先准备多个需要写^的数值，然后在一个原子操作中一并写人。

（*）原子操作和事务：在客户端和服务器之间发送的每一条属性协议的信息都隶属于某个事务（transaction）的一部分。事务可以是一条请求及其回响应，也可以是一条指示及其确认信息。事务的重要性在于它限定了连续的事务之间需要保存的信息的数量。这意味着当某设备接收到一条请求后，它无须为了处理下一条请求而保存当前请求的任何信息。关于事务模型，另一个重要的性质是在一个事务结束之前不能发起新的事务。例如，设备发送了一条读取某属性的请求，在收到相应的响应之前，不允许其发送另一条请求。事务仅针对单个设备。发起事务的设备虽然不能初始化另一个事务，但可以处理其他配对设备的请求。

命令和通知：属性协议里还有两种信息，分别是命令和通知。借助这两者，设备得以将信息发送给另一台设备，并且在发起下一条命令或通知之前无须等待相应的响应。当你正处于某个事务，却需要发送一条特定的命令或通知，这种性质便很有用。命令和通知无需响应或确认，这也意味着发送设备无法知道信息是否被对方收到并处理。对一些请求需要响应、指示需要确认的应用场景，这种性质并不适合。然而对另一些应用场景，它们却能满足要求。无需响应与确认的一个副作用在于设备可以借此发送任意多的信息。

准备写入请求与执行写入请求：事务规则还有一个例外，那便是准备写人请求与执行写人请求消息。用这些信息，设备可以准备一系列的写入操作并在—个事件中执行。从事件的角度来看，每一条准备写入请求及其响应属于—个单独事务。另外，在准备和执行操作的中途，允许插人其他请求。低功耗蓝牙有一定的数据保护能力，所有载荷中的二进制位都用了2位循环冗余校验码(CRC)，最多可检测5位错误。如果一个收到的包中有6位错误，CRC错误地接收这个包的可能性极小。下一层保护是每一个加密包中的32位消息完整性检查(MIC)值。虽不能确保检出所有的无效包，但它应该能够丢弃掉绝大部分通过了CRC校验的错误散据。因此，一个错误的包能够通过所有校验的可能性极小。

（*）分组：通用属性规范协议仅仅定义了一个属性的平面结构。每一种属性有一个地址——句柄。但现代数据组织的方法论需要的是一个更加复杂的结构而不是这样简单的平面结构。这便是属性规范的意义所在：它定义了多组属性，而不只是一组属性。我们可以把属性用页面来划分，每一页定义了一些数值。每一页面为特定的用途而定义，例如用一个页面描述设备，设备使用电池的话则要用另一个页面，再用一页面来公开温度。就达到了分组。

（*）服务：在软件工程中，当你定义并实现某个类的行为时，一旦该类的接口确定下来系统的其他部分便能重新使用基于该类的对象。这也意味着若该类中出现错误，你只需一次性的修复它，系统中其他使用该类的部分便能立刻从该修复中获益。在低功耗蓝牙中，通用属性规范定义了两种基本的分组模式：服务分组模式与特性分组模式。服务等同于一个具有不可变接口的对象，一般包含一种或多种特性，并能引用其他服务。特性是数据的单位或公开行为的单位。这些特性是自解释的，这样一般的客户端便能读取、显示这些特性。

结合服务：把接口从实现中分离了出来。有时，我们需要将与某个服务相关的两个独立的服务实例结合起来(combine)．并使其具备额外的行为。为了用服务来满足这种需求，我们必须定义第三种服务，该服务分别引用了原来两种服务。例如有某服务的两个实例：服务A:1与服务A:2．需要把它们融合在一起并具备额外的“组合”行为。如下图所示：实例化第三个服务——服务C．它引用了Al与A2两种服务。

在处理服务A:l与A:2对，服务C可以公开所需要的行为；它封装了结合后的服务的行为。例如灯光服务和日光传感器服务可以结合在一起来提供这样一种服务：让灯只能在投有日光的情况下打开。服务结台后的状态机会包含一些基础服务没有的状态。独立的A:1与A:2服务仍然具有各自不可变的行为。这意味着服务C必须能够清楚地区分组台服务的行为和独立服务的行为。

即插即用的客户端应用：服务模型还有个有趣之处，即可以使用某设备上的服务树的集合，并搜寻能使用这些服务树的应用。为此，通用客户端会先进行一次完整的服务枝举：先是首要服务，随后是它们与所引用的服务之间的关系。一旦建立了服务树，就能将服务的“森林”递交给应用库，由此获得能够与该服务森林的整体或局部协作的应用。

（2）特性

将—个服务的属性归类到一起．可以更好地说明这些属性的组合如何为行为提供一致的接口。低功耗蓝牙的体系结构也使得通过属性分组公开服务的状态和行为成为了可能。特性只是一个数值。它可以是当前的温度、某人骑行的距离或是时间同步有限状态机的状态。当然，特性的意义远不止这些。特性还需要指明数值的数据类型，数值是否可读或可写，如何配置数值的指示、通知、广播，数值的含义等。

特性包含三个基本要素：

 声明、数值、描述符

特性声明：特性性质是一个八位宇段，确定了特性数值属性对一系列操作的支持情况，包括读取、写入、通知、指示、广播、命令、签名认证。如果设置了该字段的某一位，就能用相应的规程来访问该特性数值。此外，如果设置了特性的广播位，就必须有服务器的特性配置描述符。类似地，如果设置了通知位或指示位，必须要有客户端的特性配置描述符。

特性数值：特性数值是一个属性，它的类型必须符合特性声明的特性UUID字段。除此以外，它和普通属性无异。

描述符：—个特性可以包含任意多的描述符。大多数描述符是可选的，正如上面解释的，我们可以根据特性声明或服务规格书来选用指定的描述符。

  特性可以包含如下的描述符：

  特性扩展性质、特性用户描述、客户端特性配置、服务器特性配置、特性表示格式、特性聚合格式、

（*）属性协议：属性协议是非常简单的协议，客户端通过它可以发现并获取属性服务器上的属性。它由六种基本操作构成：

  请求、响应、命令、 指示、 确认、 通知、

（3）、通用属性规范

属性的最后一个未解之谜是通用属性规范（GATT）规范。属性协议定义了客户端与服务器如何发送符合标准的消息，而GATT规程则定义了如何发现与使用服务、特性与描述符的标准方法。GATT规程可以分为三种基本的类型：

       发型规程、 客户端发起规程、 服务器发起规程

（*）客户端发起规程：对于特性，客户端可以执行四种相关操作

  读取特性值、  写入特性值、  读取特性描述符、写人特性描述符

（*）服务器发起规程：并不是所有规程都由客户端发起，有一些由服务器发起，例如通知与指示。通常由客户端配置服务器来发送这些消息，或者通过向服务器发送命令来生成消息并引发传输。有两种GATI规程是由服务器发起的：

  通知、 指示

3、安 全

安全是个相当复杂的课题，对许多人来说好比一个黑匣子。知道某一种技术是“安全”的，这对大部分人来说就可以了。然而，倘若要真正理解低功耗蓝牙的安全性，你会发现要了解的东西还真不少。安全性包括了下列内容：

  认证、  授权、  完整性、  机密性、  隐私

（1）认证：

认证是一种证明身份的方式，用来证实所连接的设备真正是其声称的设备，而非第三方

攻击者。认证采用了下列两种基本方法：

  初始认证和秘密共享、使用预先共享的秘密重新认证

（2）、授权：

  授权是指分配权限做某事，通常包括两种方式：

  文档提供授权、 直接进行授权

（3）、完整性：

完整性的定义是指数据的内部一致性和无讹误性。无论使用有线还是无线通信协议，数据从一个设备传送到另一个设备时都容易产生各种错误。因此，错误检测和防范非常重要。

（4）、机密性

机密性是指将事物保持机密的意图。机密性最常见的代表是在电影中，你会看到标有“机密”字样的公司文件或政府报告。不幸的是，把这个词印在文件上其实并不妥当，因为任何人只要看到就可以阅读它们。在低功耗蓝牙中，机密性意味着即使一个第三方窃听者接收到一个消息，她也无法解码。消息的编码过程称为加密。第二次世界大战期间开发的恩尼格码机是一个可以加密或解密消息的设备的经典例子。

（5）、隐私：

另一个安全的关注点在于任何沟通都应是私人的。完全的匿名性很难做到，例如有一个名人登机，有许多人会通过他的样子认出他。因此，要在每一个位置授予完全匿名性几乎是不可能的。因此，隐私是能够防止他人根据你的设备认出你，而且无法在一个空间跟踪你的运动的能力。

（6）、配对和绑定：

为了保证低功耗蓝牙的绝大多数安全特征，必须完成两件事情：首先，设备必须互相配对；其次，连接一旦加密，设备必须分配用于加密、保障隐私并对消息进行验证的密钥。只要密钥被保存下来，设备就处于绑定状态了。

（*）、配对：起初未提供安全性的两个设备如果希望做一些需要安全性的工作，首先必须彼此配对。配对涉及两个设备的身份认证、链路加密以及随后的密钥分配，这会使两个设备在第二次重连时的安全启动速度大为加快。

  配对有三个不同的阶段：

  配对信息交换、 链路认证、 密钥分配

配对信息交换：配对的第一阶段涉及配对信息的交换，该信息用于碗定设备的配对方式，以及确定在最后的阶段将会分配哪些密钥。低功耗蓝牙使用的配对过程和经典蓝牙的安全简单配对( secure simple pairing)相同。

（*）、认证：利用配对请求和配对响应消息所携带的信息，两个设备得以确定适合的配对算法。

（*）、密钥分配：连接一旦利用了STK加密，就可以分配所需的密钥了。这些密钥每次分配一个，固其长度为128位，每一个数据包只能装进一个。

  以下密钥可以分配：

      LTK、IRK 、 CSRK

一个必须考虑的问题是，在配对时使用的地址可能并不是设备的真实地址；配对期间可以使用随机地址或私有地址。因此，分配两个设备的身份信息就变得非常有用，该信息可用作数据库的唯一键值，使得未来设备间可以采用该身份信息进行连接，而非可能已经过期的随机地址。

（*）、绑定：绑定真正来说属于通用访问规范的讨论范畴，然而，此刻也不妨考虑一下它的操作。绑定指的无非是将密钥及相关身份信息保存到安全数据库当中。如果设备不保存这些值，它们虽能匹配，但却不能绑定。只要当中某一个设备不保存，重新连接后，只有一个设备拥有LTK，因此加密的启动将会失败。

（7）、数据签名

当一个设备已经连接但尚未加密时，可以发送设有保密性的认证数据。要实现这一点，

第一次连接配对时应当交换CSRK。在此之后，只要没有具有保密性要求的数据需要交互，

就可以使用签名。数据签名采用CMAC算法。该算法需用到进行身份验证的消息、一个签名计数器( Sign Counter)和用来验证发送方的CSRK，之后生成一个签名值。

4、通用访问规范

要理解低功耗蓝牙，最重要的是了解两个设备之间如何能发现对方、与对方协作以及不断找到对方并彼此连接。这些都在OAP当中定义。

（1）、初次发现：

 发现性包括两种类型：第一类为“有限可发现性”，由那些临时设置为可发现状态的设备使用。例如，当设备第一次接通电源时，它将进入有限可发现模式；或者如果设各有一个专门的按钮，按下它时会令设备暂时进人该模式。设备不允许长期停留在有限可发现模式，这是因为这一模式的目的是让设备从众多采用一般可发现模式的设备中脱颖而出。如果设备都在有限可发现模式下维持很长一段时间，它们就无法凸显自己。因此，一个设备只能保持有限可发现模式约30s。第二类为“一般可发现性”，由那些最近没有执行过交互的可发现设备使用。例如，如果一台计算机是可发现的，其他设备都可以找到并连接到它，但它最近没有启用过该功能，一旦启用，它将进入一般可发现模式。一个寻找其他设备的设备通常会把一般可发现设备排在设备列表的下方，这是因为较之有限可发现设备，它们的紧迫性相对较低。因此，利用不可发现设备、有限可发现设备、一般可发现设备、路径损耗范围过滤和基于服务的过滤，可以为用户提供一个直观的界面。

（2）、GAP角色

低功耗蓝牙设备定义了四类GAP角色

 广播者、观察者、外围设备、 中央设备

（*）、广播者：是发进广播报文的设备，通常广播一些服务数据给处于观察者角色的设备。广播者必须有发射装置，但是不一定有接收装置。比如一个纯广播设备就只需装配一个发射装置即可。

（*）、观察者：是扫描广播者、并且将信息报告给应用的设备。观察者必须有接收装置，也可以选装发射装置。

（*）、外围设备：是利用可连接广播报文进行广播的设备。因此一旦连接，它将成为从设备。外围设备必须同时拥有发射和接收装置。

（*）、中央设备是向外围设备发起连接的设备。因此一旦连接，它将成为主设备。中央设备也必须同时拥有发射和接收装置。

GAP定义了下列模式：

  广播模式、 不可发现模式  、有限可发现模式、一般可发现模式  、不可连接模式、 定向可连接模式  、无向可连接模式 、不可绑定模式  、可绑定模式

  GAP定义了下列规程：

  观察规程  、有限发现规程、一般发现规程、名称发现规程  、自动连接建立规程 、一般连接建立规程 、选择性连接建立规程 、 直接连接建立规程、  连接参数更新规程、  终、止连接规程 、绑定规程

（3）、安全模式

  安全模式和级别的定义如下：

  安全模式1等缎1：无安全性

  安全模式l等级2：带加密的未认证配对

  安全模式l等级3：带加密的认证配对

  安全模式2等级1：带数据签名的来认证配对

  安全模式2等级2：带数据签名的认证配对

  当两台设备之间无需安全要求时，使用安全模式l等级l。这是链路的默认安全级别。当要求数据机密性但是不要求认证（或难以进行认证）时，使用安全模式l等级2。当然，在该安全级别下，也可以在加密链路上发送投有安全性要求的数据。 当对数据的机密性和认证均有要求时，使用安全模式l等级3。这是强度最高的安全模式等级。当然，在该安全级别下，也可以在链路中传输那些只箍较低安全级别的数据。 安全模式2等级l用于既不需要数据的机密性又不需要认证的场合。当不需要数据机密性但是需要身份认证时，使用安全模式2等级2。当然，在使用认证的链路中也可以传输无需认证的数据。

（4）、广播数据

设备在发送广播报文时，必须遵循固定的广播数据格式或扫描响应数据格式。格式指的是一串广播数据结构。各结构的开始处均含有一个长度字段，表示该结构其余部分的字节长度。紧接着长度的是广播数据类型宇段，通常为1个字节，也可能是两三个字节或更长。假如不认识某广播数据类型，设备可以将其忽略并跳到下个结构。结构内的其他任何数据字节都由数据类型决定。