如何分析HCI的Command Packet和Event Packet包
如下（详细参照bt_hcip.h）：
| enum HCI_TYPE { COMMAND_PACKET = 1, DATA_PACKET_ACL = 2, DATA_PACKET_SCO = 3, EVENT_PACKET = 4, ETYPE_FINISH = 5 }; |
需要指出的是COMMAND_PACKET方向是从Host写入到Controller，EVENT_PACKET为Controller发送给Host，即单向的数据。而DATA_PACKET_ACL和DATA_PACKET_SCO为双向的数据，即可以Host-Controller，也可以Controller-Host。
接下来看两个与发包和收包相关的函数的定义，如下：
| int HCI_WritePacket(HCI_TYPE eType, BD_BUFFER *pBuff) int HCI_ReadPacket(HCI_TYPE *peType, BD_BUFFER *pBuff) |
其第一个参数etype就是用来表示R/W Packet的类型，第二个参数为包的具体数据：
所以通过在 HCI_WritePacket()/ HCI_ReadPacket()中对eType值的判断，很容易知道是 Command Packet，还是 Event Packet。>> Command
首先来看HCI包的结构：
其中低10个bit用来表示HCI Command的OCF域，可以拿着这个值到BlueCore Spec中去查询对应的命令，而bit10～bit15用来表示OGF域。对于OGF即使HCI命令的种类，具体的种类包括Link control， Link PolicyController&BaseBand以及Information等。
For example，HCI_Disconnect在MS-Stack的定义值为0x0406，具体参照文件bt_ddi.h。而其OCF域，也即bit0～bit9为0x006，对应的OGF域，也即bit10～bit15域为0x01。根据BlueCore Spec的定义，OGF为1表示Link Control Command。所有HCI Packet的定义在Volume 2-Core System Packet Part E-Host Controller Interface的Chapter 7th-HCI Command and Events中定义（以BlueCore Spec2.1为例），查询7.1th-Link Control Command一节，对应的Command Code为0x006，其对应的Command应该是HCI_Disconnect，如下所示：
下面举一个具体的Command Packet分析过程：
| Write(1, 25): 0B 04 16 77 89 39 98 22 00 54 0B 3F 42 F8 38 EE 90 09 BC 1D 1C 1E D1 E2 61 G=0x1, code=0xb |
首先看OCF（bit[0~9]）为0x0b，而OGF（bit[10~15]）为0x01，对照BlueCore Spec，则该条命令应该为Link Controller Command域中的HCI_LINK_KEY_REQUEST_REPLY（0x0b），Parameter Total Length（bit16～23）0x16，为该命令的解释如下：
根据该命令的详细解释，其参数包括两部分BT_ADDR和Link_key，分别占用6字节和16字节，所以BT_ADDR为77 89 39 98 22 00，而Link_key为54 0B 3F 42 F8 38 EE 90 09 BC 1D 1C 1E D1 E2 61。
所以，可以看到分析Command Packet的关键在于两点，第一点是根据Packet找到OCF，OGF以及total parameter length，然后找到该command的详细解释，即包含了那些参数以及每一个参数的具体长度，就可以来对Command Packet进行解析了。
>> Event
首先，来看Event Packet的结构：
下面以一个具体的Event Packet来进行分析：
| Read(5, 8): 17 06 77 89 39 98 22 00 |
很容易可以看出，Event Code为0x17，Parameter Total Length为0x06。由于Event没有域之说，可以直接拿着0x17去BlueCore Spec中的Events中去查找对应Event Link Key Request，如下：
根据该Event的详细解释，其参数为BT_ADDR，共占用6个字节，即为77 89 39 98 22 00。
对于HF等基于RFCOMM的Profile不能够正常连接的情况，在分析AirTrace LOG 时候，而查看RFCOMM选项卡中有Frame Type为DISC的命令，一般我们将其可能的一种原因解释为两个蓝牙设备之间通信出现了问题，诸如外部蓝牙设备接收到了不能够识别的命令，所以主动发起了一次DISC动作，而在DISC对应的前面Frame，我们一定能够找到不正常的Frame。
那么这种做法的理论依据是什么呢？
Core V2.1+EDR 2.5 Error Handling一节中提到如下“Erroneous LMP messages can be caused by errors on the channel or systematic errors at the transmit side. To detect the latter case, the LM should monitor the number of erroneous messages and disconnect if it exceeds a threshold, which is implementation-dependent.”可以看到，在BT设备侦测到错误达到一定程度的时候，将会发起Disconnect动作。
蓝牙Profile
Bluetooth的一个很重要特性，就是所有的Bluetooth产品都无须实现全部 的Bluetooth规范。为了更容易的保持Bluetooth设备之间的兼容，Bluetooth规范中定义了Profile。Profile定义了设备如何实现一种连接或者应用，你可以把Profile理解为连接层或者应用层协。
在所有的Profile中，有四种是基本的Profile，这些Profile会被其它的Profile使用，它们包括GAP/SDAP/SPP/GOEP Profile。
1.1 GAP
GAP Profile: Generic Access Profile，该Profile保证不同的Bluetooth产品可以互相发现对方并建立连接。
一般访问应用规范（GAP）定义了蓝牙设备如何发现和建立与其他设备的安全（或不安全）连接。它处理一些一般模式的业务（如询问、命名和搜索）和一些安全性问题（如担保），同时还处理一些有关连接的业务（如链路建立、信道和连接建立）。GAP规定的是一些一般性的运行任务。因此，它具有强制性，并作为所有其它蓝牙应用规范的基础。
1.2 SDAP
SDAP Profile: Service Discovery Application Profile，通过该Profile，一个Bluetooth设备可以找到其它Bluetooth设备提供的服务，以及查询相关的信息。
1.3 SPP
全称Serial Port Profile，定义了如何在两台BT设备之间建立虚拟串口并进行连接。
例如，在两台电脑或者Labtop之间就可以建立这种连接，如下图所示：
1.4 GOEP
GOEP Profile: Generic Object Exchange Profile，通用对象交换。这个Profile的名字有些费解，它定义的是数据的传输，包括同步，文件传输，或者推送其它的数据。可以理解为与内容无关的传输层协议，可以被任何应用用来传输自己定义的数据对象。
1.5 A2DP
A2DP 全名是Advenced Audio Distribution Profile 蓝牙音频传输模型协定。
A2DP 规定了使用蓝牙非同步传输信道方式，传输高质量音乐文件数据的协议堆栈软件和使用方法，基于该协议就能通过以蓝牙方式传输高品质的音乐了。这个技术可以利用立体声蓝牙耳机来收听手机中的音乐了。
所谓的蓝牙其实包括很多版本以及小的功能规范子集，其中一个叫做 A2DP（Advance Audio Distribution Profile） 的，是专门为使用蓝牙传送立体声音乐而制定的只要两个蓝牙设备均支持这种规范，那么即可以实现无线传送立体声音乐。
1.6 DUN
全称Dial-up Networking (DUN) Profile，实现一台蓝牙设备通过另外一个带无线功能的蓝牙设备共享上网。
如下图所示：
参照http://msdn.microsoft.com/en-us/library/cc510743.aspx。
1.7 VRCP
AVRCP（Audio/Video Remote Control Profile），也就是音频/视频远程控制配置文件。
AVRCP 设计用于提供控制TV、Hi-Fi设备等的标准接口。此配置文件用于许可单个远程控制设备（或其它设备）控制所有用户可以接入的A/V设备。它可以与 A2DP 或 VDP 配合使用。
AVRCP 定义了如何控制流媒体的特征。包括暂停、停止、启动重放、音量控制及其它类型的远程控制操作。AVRCP 定义了两个角色，即控制器和目标设备。控制器通常为远程控制设备，而目标设备为特征可以更改的设备。在 AVRCP 中，控制器将检测到的用户操作翻译为 A/V 控制信号，然后再将其传输至远程 Bluetooth 设备。对于“随身听”类型的媒体播放器，控制设备可以是允许跳过音轨的耳机，而目标设备则是实际的播放器。常规红外遥控器的可用功能可以在此协议中实现。
AVRCP 协议规定了AV/C 数字接口命令集（AV/C 命令集，由1394 行业协会定义）的应用范围，实现了简化实施和易操作性。此协议为控制消息采用了AV/C 设备模式和命令格式，这些消息可以通过音频/视频控制传输协议 (AVCTP) 传输。
1.8 HID
HID全称Human Interface Device Profile, 即人机接口设备Profile.
Provides support for devices such as mouse, joysticks, keyboards, as well as sometimes providing support for simple buttons and indicators on other types of devices. It is designed to provide a low latency link, with low power requirements.
Bluetooth HID is a lightweight wrapper of the Human Interface Device protocol defined for USB. The use of the HID protocol simplifies host implementation (ex: support by Operating Systems) by enabling the re-use of some of the existing support for USB HID to also support Bluetooth HID.
Popular devices that feature support for this profile include: Logitech diNovo Media Desktop 2.0, Microsoft Optical Desktop Elite for Bluetooth. PlayStation 3 controllers and Wii Remotes also use BT HID.
更加详细的内容，请参考http://en.wikipedia.org/wiki/Bluetooth_profile和http://www.bluetooth.com/English/Technology/Works/Pages/default.aspx。
2. 协议体系结构
整个协议体系结构分三大部分：底层硬件模块、中间协议层和高层应用。
2.1 底层硬件（这些一般集成到BT HW Module中）
RF （Radio Frequency) RF层通过2.4GHz 无需授权的ISM频段的微波，实现数据位流的过滤和传输
BB (Baseband，BB) 跳频和蓝牙数据及信息帧的传输
LM (Link Manager)。 连接的建立和拆除以及链路安全和控制
2.2 中间协议层
L2CAP (Logical Link Control and Adaptation Protocol) 数据的拆装、服务质量和协议复用等功能
SDP (Service Discovery Protocol) 提供一种机制来发现网络中可用的服务及其特性
RFCOMM 串口仿真协议，仿真9针RS232串口
TCS (Telephony Control Protocol) 蓝牙设备间话音和数据的呼叫控制信令
2.3 高层应用框架(Profiles)
拨号网络(Dial－up Networking)、耳机(Headset)、局域网访问(LAN Access)、文件传输(File Transfer)等海油很多种，
各种应用程序可以通过各自对应的Profile实现无线通信.