BlueTooth探索系列（一）---JSR082 API框架剪影

可以自由转载, 转载请保留下面的作者信息:

作者 cleverpig(http://www.matrix.org.cn/blog/cleverpig)

一、JSR082 API框架：

1.API分类：JSR82的API从功能上分为3大类：
1).发现：包括设备/服务发现，服务注册；
2).通讯：包括建立设备之间的连接、使用这些连接；
3).设备管理：可以负责管理和控制连接。
所以这3类的关系主要是：设备管理-(管理)->通讯-(实现)->发现。

2.开发包划分：
1).javax.bluetooth:提供实现蓝牙功能的API。
2).javax.obex:提供无线上OBject EXchange的API。
这两个包是各自独立的，互相没有依赖关系。但是他们都依赖javax.microedition.io包。

3.MIDP与Bluetooth API的关系：
1).CLDC：连接受限制设备配置，即KVM，提供了基本的java语法安全验证和sandbox的安全功能。但是由于设备的处理能力有限，这里的验证只是通过预验证实现的，即把验证的工作放在了计算机上，而不是j2se中的编译和类装载时的安全验证。
只包含了java.lang、java.io、java.util这三个功能有限的包。
2).MIDP：移动信息设备框架，位于CLDC的上层，对CLDC的基本功能进行扩展。提供了网络和多媒体、存储功能。
3).Bluetooth API：蓝牙应用程序接口。与MIDP平级，但独立于MIDP，可与MIDP或CLDC共存。

4.蓝牙控制中心(BCC)：
　　实现Bluetooth API的蓝牙设备，允许多个应用同时执行，这就需要BCC来避免一个应用与其它应用发生冲突。BBC具有允许用户或者OEM在蓝牙堆栈中定义某个配置的指定值，并解决由使用蓝牙API的应用所造成的冲突请求。
　　所以BBC是本地蓝牙设备设置的核心授权者，它的细节留给了实现：它可能是厂商提供的一个使用一个单独的API或者一组简单的配置本地应用程序，不能被使用者修改。

下面谈一下BBC与安全模式的关系：
　　从最基本的层面来看，BCC定义设备相关的安全设置。例如，BCC控制虚拟机中一个栈所使用的安全模式，维护着信任设备的列表。这个API允许应用某个应用指定它的安全要求：认证、加密、授权。JSR82实现了与BBC接口，来对所有应用的安全要求作出公断。
　　BCC在API中不是一个类也不是一个接口，但它是JSR82这个规范安全框架的重要部分。蓝牙无线技术的Java API需要BCC才能完成对程序的安全保证。BBC是依赖实现的，它只是可能用java开发的，具体的情况按照移动设备生产厂商不同而定。
BCC的特点：
BCC必须提供以下功能的API实现：
1).设备的基本设置，包括在蓝牙规范中定义的安全模式；
2).一个本地设备已知的远端蓝牙设备（并不必要为邻近的蓝牙设备）列表；
3).一个本地设备信任的远端蓝牙设备（并不必要为邻近的蓝牙设备）列表；
4).一种尝试无线连接两个设备的机制；
5).一种提供连接授权的机制。
以上这些信息只能被BCC所改变。
BCC可以提供，但是不被限制的行为：
1).设置本地设备的蓝牙设备名字；
2).设置基带层的超时；
3).检测可连接/可发现模式如何被设置；
4).重置本地设备；
5).枚举本地设备上的服务。

5.设备属性：
　　一些java技术适用的蓝牙产品需要根据产品和市场的需要进行不同的配置。所以设备属性API便应运而生了。这个定义了可以通过调用LocalDevice.getProperty()方法而返回的附加设备属性，如设备版本、MTU最大值等。这些属性既提供了蓝牙设备的附加信息而且定义了可被应用替换掉的限制。这些“String”类型的属性如果没有被定义或者未知，那么其属性值为null。
这里需要解释的是Page scan、Page、Inquiry、Inquiry scan。
这些属性与蓝牙设备无线连接过程密切相关：
Inquiry：首先主（Master）设备使用GIAC或DIAC查询周围的蓝牙设备；
Inquiry Scan：同时工作在副（Slave）设备模式下的蓝牙设备侦听Inquiry；
Inquiry Response：如果副设备接收到来自主设备的Inquiry，它将发送自己的设备地址和时钟信息给主设备；
Page Scan：在发送Inquiry Response后副设备将进入侦听从主设备发来的广播信息（Page message）的状态；
Page：主设备收到Inquiry Response后发现了周围的蓝牙设备后，广播建立连接所需要的信息；
Slave Response：处于监听状态的副设备收到广播信息后，将自己的设备访问代码回应给主设备；
Master Response：主设备收到Slave Response后将传输主设备的时钟和设备地址、设备类型回应给副设备；
Connection State：在副设备接收到Master Response后，双方就进入了连接状态。

6.C/S模式：
　　一个蓝牙服务是一个类似server的应用，它提供了client设备上不具备的功能。比如打印服务就是一个蓝牙服务的例子。开发者可以在蓝牙框架之上自己定义自己的蓝牙服务应用，并通过定义一个描述服务信息的服务记录，并将该服务记录添加到服务发现数据库（SDDB），提供给远程设备使用。
在注册服务记录后，server应用程序等待client开始与它的交互、并访问服务。而另一方面，client和server程序建立蓝牙连接，进行它们之间的交互。
　　从某个角度看，server应用好像超出了蓝牙规范的范畴，那样的话，就像蓝牙发展的前期多个厂商实现各自的蓝牙协议堆栈，没有要求标准化以确保不同蓝牙设备之间的互通性一样。那一定是一场灾难。不过，一套标准化的API的出台将改变这一种混沌的局面。
这套API将server应用、client应用、蓝牙堆栈三者的责任分离开来：

server应用的责任：
1).建立表述应用提供的服务的服务记录（service record）;
2).添加服务记录到server的SDDB，使client能够使用之;
3).注册在与client连接中使用蓝牙安全策略;
4).接收来自client对服务的请求;
5).当服务记录的特性改变时，即使更新server的SDDB中的服务记录;
6).当服务失效时，删除或者禁用server的SDDB中的服务记录.

client应用的责任：
1).使用服务发现协议(SDP)查询远端设备的SDDB;
2).注册在与server连接中使用的蓝牙安全策略;
3).开始连接提供服务的server;
4).可选的，轮询server的SDDB以确定服务是否改变或者失效.

蓝牙协议堆栈提供给本地蓝牙server应用的特性：
1).一个允许server添加、更新、删除它自己的服务记录的服务记录仓库;
2).给每个服务记录赋予一个唯一的服务记录句柄;
3).建立与client的逻辑连接.

蓝牙协议堆栈提供给远端执行服务发现的client应用的特性：
1).查询并接收保存在server的SDDB中的服务记录;
2).建立与server的逻辑连接.

BlueTooth探索系列（二）---发现服务框架

二、Service Discovery Protocol：

1.Service Discovery Protocol适用范畴：
　　自由的使用蓝牙设备上的服务是我们所期待的目标，但是这些蓝牙设备上提供的服务是以一种不可确定甚至无法控制的方式动态增减着。为了帮助使用蓝牙设备的用户有序地罗列出每次都在变化的服务，并从中选择一些为他所用，JSR组织制定了Service Discovery Protocol（简称SDP）——服务发现协议。当遇到未知蓝牙服务时，遵守这个标准化的框架的蓝牙产品将能够定位服务所在位置，识别和有选择的使用服务。蓝牙协议堆栈包含了SDP，这个协议能够在周围的蓝牙设备中定位有效的服务提供给用户，作为用户选择服务使用的依据。有关选择、访问、使用服务的内容不属于本文的范畴，然而尽管SDP没有直接的被防问服务所调用，但通过将SDP所获得信息作为属性条件来让本地蓝牙协议堆栈访问指定设备的方式对使用指定设备上的服务起到了极其重要的促进作用。
　　SDP协议框架定义了在一个蓝牙设备上运行的服务发现应用所要使用的协议和过程两个方面：服务发现应用按照这个协议和过程来定位其它设备上的服务并使用它们。从这个框架的角度来看，服务发现应用是一个特定的由用户发起的应用。从这个框架与其它的蓝牙协议框架的比较看来，两者是不同的：服务发现工作与两个在蓝牙设备中的SDP实例交互，其目的是使用某个特定的传输服务（RFCOMM）或者特定的用途（文件传输、无线电话、LAN AP等）。其中后者（将服务用于特定的用途）的详细描述在相应的Bluetooth usage scenarioprofile（蓝牙用途框架）文档中可以查到。在其它的框架文档中，服务发现也出现在了一些地方：协议讲解、访问某个特定服务需要的协议参数等。无论怎样，SDP框架说明了服务发现的过程和在这些过程中如何使用SDP协议。与在其它框架文档中不同的是这些过程在SDP框架中被用在了用户层面，而其它的框架文档中将它使用在了应用级别的行为上。

SDP直接支持以下几种服务查询：
1).通过服务类进行服务查询；
2).通过服务属性对服务进行查询；
3).服务浏览。
一般的服务发现应用都被以上的三种服务查询所覆盖。其中前两个代表了查询已知或者指定的服务，并对类似“服务A是否有效？”或者“具有B和C特性的服务A是否有效？”的问题作出了回答。后面的服务浏览代表了另外一种服务查询，对类似“有效的服务有哪些？”或者“有效的类型A的服务有哪些”的问题给出解答。

上面的服务查询段落可以被实现为两种方式：
1).用户有意识地连接到某个设备，并查找这个设备上的服务；
2).通过无意识地连接本地设备周围的设备，并执行服务查询。
这两种实现方式都需要设备首先被发现、被连接、被查询它们所支持的服务。

BlueTooth探索系列（三）---发现服务框架(续)

2.SDP概貌：
1).SDP框架的堆栈：

上图显示了蓝牙协议和使用SDP的应用实例。
如图中，SrvDscApp这个服务发现用户应用位于本地设备LocDev上，通过与蓝牙SDP客户端的接口，发送服务查询请求并接收从位于远端设备RemDevs上的SDP服务器的服务查询响应。SDP使用了面向连接的L2CAP协议来传输服务，这种L2CAP协议使用基带异步无连接（ACL）来实现最终装载/传输SDP的PDU（协议数据单元）。
服务发现过程以与发现设备过程密切相关，发现设备过程又与执行设备查询和设备捆绑的过程密切相关。这样，这个SrvDscApp应用通过使用BT_module_Cntrl实例与基带进行接口，而用BT_module_Cntrl实例在进入查询模式的操作时负责指挥蓝牙模块。
注：BT_module_Cntrl可以是蓝牙协议堆栈实现的一部分或者是SrvDscApp应用的一个低级部分。正因为这样，也没有关于任何特定协议堆栈或者SrvDscApp应用实现被完成的假设，BT_module_Cntrl实例代表着一个与SrvDscApp分离的逻辑实体，它既不是SrvDscApp的一部分，也不是协议堆栈的部件或者任何相应的代码片断。
服务记录数据库在上图中显示在SDP server的右侧，它是一个逻辑实体，工作起来就像服务发现的相关信息的仓库，可被client用来查找特定服务，可被server用来发布服务。

2).配置与角色：
以下角色被定义在SDP框架中：
本地设备（LocDev）：本地设备是一个发起服务发现过程的设备。它必须至少包含蓝牙SDP框架的客户端部分：被用户用来发起发现服务过程的服务发现应用（SrvDscApp），显示发现结果的显示功能。
远程设备（RemDev）：远程设备是一种参与服务发现过程，对来自本地设备LocDev的服务查询请求作出回应。它必须包含蓝牙SDP框架中的服务器部分：即包含一个服务记录数据库，用来组成对服务发现请求的回应部分。

赋予一个设备的LocDev或者RemDev角色不是永久的也不是唯一的。某个RemDev可能像SDP客户端那样安装了SrvDscApp，而某个LocDev也可能有一个SDP Server。对于一个安装了SrcDscApp、SDP客户端、SDP Server的设备，这个设备的角色赋值是由每次的SDP会话过程决定的。因此，一个设备可以在一个特定的SDP会话中担任LocDev角色，也可能在另一次SDP会话中担任RemDev角色。由上图看出，一个没有UI的设备，不能接收用户输入并显示服务查询的结果，那么这个设备就不被看作是LocDev的候选者。但无论如何，即使这样一个设备不被看作是一个LocDev的候选者，如果运行在这个设备上的应用需要执行服务发现会话时，在下面章节的过程描述仍能应用。

上图是一个典型的服务发现结构。图中notebook作为本地设备正在查询周边的远程设备上的服务。

         3)用户需求和使用场所：
         本框架涉及的用途如下：
         A.通过服务类查询服务；
         B.通过服务属性查询服务；
         C.浏览服务。
         前面的两个用途是用在寻找已知的某个特定服务时的，例如用户要查找A服务或者具有B和C特点的A服务是否有效；而第三类用途则适用于通用的服务查询，例如在用户的手持蓝牙设备周边查找那些服务可用时。上面的例子中本框架的使用依赖于支持蓝牙协议的用户应用程序—SrvDscApp，这个应用在一个LocDev设备中通过与SDP协议接口来定位服务。从这个层面看，本框架与其它框架具有独到之处：SDP框架是通过一个描述与某个特定蓝牙协议接口的应用实现开发者设计的目标—最大的满足最终用户需要。

         4)SDP框架基础：
         在两个嵌入蓝牙的设备互相通讯之前必须经过以下过程：
         A.设备需要加电和初始化。初始化过程可能需要为建立蓝牙链路和设备授权和数据加密提供一个PIN（个人标识号码）。
         B.一个蓝牙链路被建立后，有一个设备发现的过程：主设备首先通过查询处理发现其它的设备的BD_ADDR，而被查询的设备则将自己所拥有的服务告知主设备。然而把LocDev设备当作主设备，而RemDev设备作为从设备的想法是看似很自然的。但这点并没有被本框架所要求。在本文档中提供的服务发现过程中，在同一个微型网络（很小的网络，也称为piconet）中任意一个设备都可能成为主设备或者从设备。而且，在这个微型网络中的一个从设备也可能在另一个微型网络中发起服务发现，即成为那个微型网络中的主设备。这样就造成了同一设备的复用冲突问题，在这种情况下，这个从设备将告知原网络中的主设备：本设备不可用（这个从设备有可能进入保持可操作模式）一段时间，当然。原网络中的主设备不能再作为另一个新的微型网络的主设备了，因为每个微型网络由这个网络中的唯一主设备的BD_ADDR来标识。

         本框架不要求必须使用授权或者加密。如果授权或者加密被某个设备所调用，则服务发现将只在这些需要授权或者加密的设备上传递授权或者加密安全保障，从而加强彼此之间的数据安全。换一个说话，只有在蓝牙链路上安全限制已经存在时才被称为SDP事务的安全限制。

         5）一致性保证：
         如果本框架的一致性被公布，则所有在本框架中被标识为强制性的设备性能都应该以某种特定的方式支持。同样这个规则也适用于所有在本框架中被标识为强制性的可选的和有条件的性能。所有在SDP框架中强制性的性能指标、可选的和有条件的性能指标都将作为蓝牙产品认证体系中的被验证的主题。

BlueTooth探索系列（四）---服务发现协议的用户接口与应用层

3.用户接口：
         1）结对（pairing）：
         SDP框架中没有硬性要求结对。也就是说结过程对可以发生也可能不发生。在一个LocDev设备对周围可连接的RemDev设备执行服务发现时，LocDev设备上的SrvDscApp应该负责允许优先结对或者旁路任何需要结对的设备。本框架只注重在LocDev建立一个合法且可用的基带链路连接到RemDev后执行服务发现的过程。
        
         2）模式选择：
         本框架假设在SrcDscApp的指挥下，LocDev设备应该进入查询和（或者）呼叫状态，而对其它设备开放服务（例如打印服务、网络数据获取和处理服务、PSTN网关服务）的RemDev设备应该进入查询扫描和（或者）呼叫扫描状态。而在蓝牙的链路控制（Link Control）中强制规定了LocDev应支持查询和呼叫状态，而RemDev应支持的查询扫描状态是可设置的设备策略，RemDev设备进入可发现模式后查询扫描状态将被激活。RemDev的呼叫扫描状态并没有在Link Control强制规定。
         因为SrvDscApp可以对已连接的RemDev设备进行服务查询，而一个LocDev设备总是作为主设备去连接一个RemDev设备并没有强制性的规定。同样一个RemDev在不总是作为从设备出现在与一个LocDev的连接中。

4.应用层：
         1）服务发现应用：
这里将讨论SrvDscApp的可操作性框架结构。下图展示了SrvDscApp可能的框架。

三种SrvDscApp的实现流程被显示在上图中，当然这三种还不能覆盖SrvDscApp实现的所有情况。SrvDscApp_A、SrvDscApp_B、SrvDscApp_C都实现了相同的目的，但是各自的遵循了不同的途径：
         SrvDscApp_A：首先在LocDev设备上的SrvDscApp获取用户提供的服务描述信息。然后SrvDscApp通过蓝牙查询过程查找周围的设备，对于每个发现的设备，LocDev将连接它，并执行必要的链路建立过程，我们可以从GAP（Gerneric Access Profile）文档中发现更多的细节，此后查询被发现的设备上是否存在用户所要的服务。
         SrvDscApp_B：首先查询设备，然后为服务查询收集用户输入的信息，
         注意：设备发现可能在SrvDscApp应用启动之前就已经发生过了，但是由于没有什么能保证设备发现已经发生过，所以推荐SrvDscApp程序再进行一次设备查询。
         SrvDscApp_C：在前两个实现流程中，呼叫、链路建立、服务发现都是在每个RemDev设备上有序的jinxing着。LocDev在没有完成前一个RemDev的服务查询并断开连接前不能进行下一个新的RemDev的查询。而SrvDscApp_C则不同于前两种实现，LocDev在SrvDscApp的控制下将呼叫所有的RemDev，然后建立与所有设备的链路（一次至多建立7个连接），查询在所有连接设备上的用户指定服务是否可用。
         举个例子，我们把上图的SrvDscApp_A看作一个SrvDscApp，这个SrvDsvApp具有下面的特点：
         •SrvDscApp根据用户要求的某个特定服务查询激活蓝牙查询，来寻找周边的可连接的蓝牙设备RemDev；
         • 当一个新的RemDev被发现后，SrvDscApp将完成服务发现并中断与这个设备的连接，尝试连接下一个RemDev；
         • 当RemDev都被连接好后，LocDev在这个连接上进行服务发现；
         • 当SrvDscApp执行连接时，SrvDscApp的用户具用信任模式操作和非信任模式操作的选择权：
         a)只与信任的RemDev连接；
         b)除了与a中描述的设备连接外，附加上与新发现的RemDev连接，而这些RemDev服务任何的信息除了提供默认的全零的PIN用于可能结对之用；
         c)除了与a和b中描述的设备连接外，附加上符合用户输入的完整非零PIN的RemDev。
         上面的选择决定于将在配置时的用户干预程度和用户与SrvDscApp交互、设置用户要求查询的服务的安全级别的程度。在选择a或者b时，设备之间将建立不正统（未经授权和加密）的连接，SrvDscApp将忽略这些信息不给用户任何的暗示。
        
         当一个LocDev执行一次服务发现查询时，它将面对下面的三种类型的RemDev：
         1.信任设备：设备当前没有与LocDev连接，但是LocDev已经与它建立信任关系；
         2.未知（新）设备：不可信任的设备，当前没有和LocDev连接；
         3.已连接设备：已经与LocDev连接的设备。
         为了发现第1或第2种RemDev，SrvDscApp需要激活蓝牙查询和（或者）呼叫进程。为了发现第3种RemDev，无论通过蓝牙查询进程这些设备是否被定为或者已经与LocDev设备连接，SrvDscApp需要访问在LocDev设备周边设备的BD_ADDR。这样BT_module_Cntr（蓝牙控制模块）应该维护一个LocDev周围设备的列表，并提供这个列表来帮助SrvDscApp工作。

         2)服务基本构成体的抽象：
         这部分主要描述SrvDscApp的功能性。SrvDscApp的功能性是用一套完整的定义了用户所期望的SrvDscApp框架表示的。当然，这里假设了SrvDscApp所依靠的蓝牙堆栈可以直接或者间接地实现这些服务基本构成体抽象所达到的目标。而“直接”的意思是指被定义的功能直接使用了蓝牙堆栈实现中的某个调用，“间接”是指被定义的功能使用了多个蓝牙堆栈实现中的调用来完成它的目标。服务基本构成体抽象的精确语法和语义具有平台（例如一个操作系统、一个硬件平台、笔记本、蜂眼电话等）依赖性，这些超出了SDP框架的范围。但是这些基本构成体的功能被期望对SrvDscApp完成它的任务有所帮助。下面的表格包含了一个能够支持SrvDscApp的最小服务基本构成体的集合。至于低级别的基本构成体如openSearch()或者closeSearch()等都作为上面的基本构成体的一部分没有显示在下面的表格中。蓝牙堆栈的不同实现至少应该具备这些服务基本构成体。
         例如，serviceSearch()服务基本构成体同时使用了多个蓝牙堆栈中单独的操作。也就是说，一个应用程序需要一个蓝牙堆栈实现，这个堆栈被应用程序调用来完成由多个独立的操作组合体反复调用所构成的功能，所以这个由多个独立的操作组合体反复调用所构成的功能就使服务基本构成体具备了功能。即使本框架中提供的这些服务基本构成体被假设作用于一个访问物理的远程设备，而这里的“远程设备”只是一个逻辑设备，如：被查询服务记录的、提供服务的是调用这些服务基本构成体的同一个设备。一个服务基本构成体只显示下一个使用蓝牙协议以无线交换数据为结果或者与无线交换数据相关的服务基本构成体之间的关系。附加的服务基本构成体能够被想象为与单纯的本地操作（如服务注册）相关，但这些基本构成体已经超越了SDP框架的范畴。

上表为SrvDscApp所支持的服务构成体列表。
注意：每个服务构成体的调用都被看作是一次primitiveHandle。
上面的stopRule参数被用于保证一次服务查询的完美终止，它表示查询过程所花费的时间。作为一个蓝牙堆栈的实现，不能暴露这个参数，因为它提供了对所有查询终止的保证。

enumerateRemDev(.)这个服务构成体直接关系到了查询模式，而且也关系到了一个LocDev所连接的RemDev的集合。这个服务通过BT_module_Cntr导出到SrvDscApp中。它在BT_module_Cntr和基带之间激活蓝牙查询并收集查询的结果集。而且它位于BT_module_Cntr和L2CAP之间，跟踪着每一个当前被LocDev连接的RemDev。
enumerateRemDev(.)的结果被用在serviceSearch(.)中用来在被发现的设备上查询特定的服务，这个服务基本构成没有被蓝牙堆栈实现明确的提供，但它已经融入到了其它的服务基本构成中（如serviceSearch(.)）。

3）消息队列图表(MESSAGE SEQUENCE CHARTS，简称MSCS)
本框架关系到三个蓝牙过程：设备发现、设备名称发现、服务发现。它们中的任意一个都不预包含另外一个；例如：为了连接一个RemDev，一个LocDev必须先发现这个设备，当然也可以询问它的设备名称。
下图罗列了本框架执行过程中所发生的关键信息交换过程。不是所有的过程都能够涉足，不是所有的设备都经过这些过程。例如如果认证不需要，下图的认证过程就不执行。如果SrvDscApp需要去查询LocDev所连接的某个特定RemDev上的服务，查询和呼叫将不执行。下图中对于每个过程都提供了其执行的条件。