此处讲述的是蓝牙HCI相关的部分,并不是特指某个具体的蓝牙协议栈,只是对蓝牙HCI结构 和技术作了总体的概述

(一)Host Controller Interface (HCI)

The HCI provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth baseband capabilities.The HCI exists across 3 sections, the Host - Transport Layer - Host Controller. Each of the sections has a different role to play in the HCI system.

(1)HCI Functional Entities

    The HCI is functionally broken up into 3 separate parts:


 蓝牙开发入门--知识疏理 - lyzaily@126 - 

1.1)HCI Firmware (location: Host Controller)

   HCI Firmware , is located on the Host Controller , (e.g. the actual Bluetooth hardware device ). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing baseband commands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device(Host Controller这一技术术语表示的是“人机交换”的蓝牙设备) .

1.2)HCI Driver (location: Host)

HCI Driver , which is located on the Host (e.g. software entity ). The Host will receive asynchronous notifications of HCI events, HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit(Host 这一技术术语表示的是“人机交互”的软件单元).

1.3)Host Controller Transport Layer   (location: Intermediate Layers)

    The HCI Driver and Firmware communicate via the Host Controller Transport Layer , i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth : USB , UART and RS232. The Host should receive asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used(Host接收HCI events事件通知与具体使用什么样的传输层无关).

2 HCI Commands

   The HCI provides a uniform command method of accessing the Bluetooth hardware capabilities. The HCI Link commands provide the Host with the ability to control the link layer connections to other Bluetooth devices. These commands typically involve the Link Manager (LM) to exchange LMP commands with remote Bluetooth devices. The HCI Policy commands are used to affect the behaviour of the local and remote LM. These Policy commands provide the Host with methods of influencing how the LM manages the piconet. The Host Controller and Baseband commands , Informational commands , and Status commands provide the Host access to various registers in the Host Controller.(HCI commands就是Link commands,HCI policy commands,Host Controller and Baseband commands , Informational commands , and Status commands的合集)。

2.1)HCI- Specific Information Exchange

   The Host Controller Transport Layer provides transparent exchange of HCI-specific information. These transporting mechanisms provide the ability for the Host to send HCI commands, ACL data, and SCO data to the Host Controller. These transport mechanisms also provide the ability for the Host to receive HCI events, ACL data, and SCO data from the Host Controller. Since the Host Controller Transport Layer provides transparent exchange of HCI-specific information, the HCI specification specifies the format of the commands, events, and data exchange between the Host and the Host Controller.(Host Controller Transport Layer提供的透明传输机制,为Host向Host Controller发送指令和数据以及从Host Controller接收返回事件,提供了传输途径)。

2.2)Link Control Commands

    The Link Control commands allow the Host Controller to control connections to other Bluetooth devices. When the Link Control commands are used, the Link Manager (LM) controls how the Bluetooth piconets and scatternets are established and maintained. These commands instruct the LM to create and modify link layer connections with Bluetooth remote devices, perform Inquiries of other Bluetooth devices in range, and other LMP commands.(Link Control Commands 主要用于命令LM如何进行连接组网,设备发现等)

2.3)Link Policy Commands

   The Link Policy Commands provide methods for the Host to affect how the Link Manager manages the piconet. When Link Policy Commands are used, the LM still controls how Bluetooth piconets and scatternets are established and maintained, depending on adjustable policy parameters. These policy commands modify the Link Manager behaviour that can result in changes to the link layer connections with Bluetooth remote devices.

2.4)Host Controller & Baseband Commands

   The Host Controller & Baseband Commands provide access and control to various capabilities of the Bluetooth hardware. These parameters provide control of Bluetooth devices and of the capabilities of the Host Controller, Link Manager, and Baseband. The host device can use these commands to modify the behaviour of the local device.

2.5)Informational Parameters

    The Informational Parameters are fixed by the manufacturer of the Bluetooth hardware. These parameters provide information about the Bluetooth device and the capabilities of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters.


2.6) Status Parameters

   The Host Controller modifies all status parameters. These parameters provide information about the current state of the Host Controller, Link Manager, and Baseband. The host device cannot modify any of these parameters other than to reset certain specific parameters.


2.7)Testing Commands

   The Testing commands are used to provide the ability to test various functionality's of the Bluetooth hardware. These commands provide the ability to arrange various conditions for testing.



3 HCI Events/ Error Codes/ Flow Control

3.1) Flow Control

    Flow control is used in the direction from the Host to the Host Controller to avoid filling up the Host Controller data buffers with ACL data destined for a remote device (connection handle) that is not responding. It is the Host that manages the data buffers of the Host Controller.


3.2) HCI Events

    A number of different events are defined for the HCI layer. The events provide a method to return parameters and data associated for each event. 32 HCI different events have been implemented so far, they range from Inquiry Complete Event to Page Scan Repetition Mode Change Event . See the main HCI specs for mode details.


3.3)HCI Error Codes

    A large number of error codes have been defined for the HCI layer. When a command fails, Error codes are returned to indicate the reason for the error. 35 HCI error codes have so far been defined, from Unknown HCI Command to LMP PDU Not Allowed. See the main HCI specs for mode details.


4  Bluetooth-defined Host Controller Transport Layers

4.1)UART Transport Layer

    The objective of the HCI UART Transport Layer is to make it possible to use the Bluetooth HCI over a serial interface between two UARTs on the same PCB. The HCI UART Transport Layer assumes that the UART communication is free from line errors. Event and data packets flow through this layer, but the layer does not decode them.


4.2)RS232 Transport Layer

   The objective of the HCI RS232 Transport Layer is to make it possible to use the Bluetooth HCI over one physical RS232 interface between the Bluetooth Host and the Bluetooth Host Controller. Event and data packets flow through this layer, but the layer does not decode them.


4.3)USB Transport Layer

   The objective of the Universal Serial Bus (USB) Transport Layer is to the use a USB hardware interface for Bluetooth hardware (which can be embodied in one of two ways: as a USB dongle, or integrated onto the motherboard of a notebook PC). A class code will be used that is specific to all USB Bluetooth devices. This will allow the proper driver stack to load, regardless of which vendor built the device. It also allows HCI commands to be differentiated from USB commands across the control endpoint.


Note, the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.





Platform Builder for Microsoft Windows CE 5.0

Bluetooth Stack Architecture

The protocol stack makes up the core portion of the Bluetooth implementation. This stack enables devices to locate each other and establish a connection. Through this connection, devices can exchange data and interact with one another through various applications.

The following image map shows the supported layers within the Bluetooth stack. To link to topics that provide information about the elements in the image map, move your pointer over the element, and then choose the element.

蓝牙开发入门--知识疏理 - lyzaily@126 - 小坏狗的博客

OBEX (Object Exchange) is an object exchange protocol that is implemented on top of Winsock over Bluetooth and IRDA transports. For more information, see Object Exchange Protocol .

  • Obex client module: Obexapi.dll
  • Obex server module: Obexsvr.dll

TDI (Transport Driver Interface), in the Microsoft® Windows® CE operating system (OS) architecture, is an interface that serves as an adaptation layer to Winsock-based user APIs. It isolates the highly asynchronous callback-based architecture of the stack presenting a Windows Sockets Specification 1.1 interface.

COM Port Emulation , in Windows CE, enables virtual COM ports to be created over RFCOMM channels. It hosts dial-up and LAN access profiles . For more information, see Creating a Connection to a Remote Device Using a Virtual COM Port . The port emulation facility is included in Btd.dll.

SDP (Service Discovery Protocol) is a Bluetooth service discovery protocol that handles publishing and discovery of services running on top of the Bluetooth stack. The port emulation is included in Btd.dll.

  • SDP client module: Btdrt.dll
  • SDP server module: Btd.dll

RFCOMM (Serial Cable Emulation Protocol) is Bluetooth's adaptation of the TS07.10 protocol. It serves as a base for COM port emulation facilities and derived point-to-point protocols. Multiplexing and flow control between devices and applications are also implemented here. The RFCOMM layer is included in Btd.dll.

PAN (Personal Area Network) profile defines procedures to support standard IP-based network services deployed over the Bluetooth transport layer. For more information, see Personal Area Networking (PAN) Profile .

HID (Human Interface Device) profile defines procedures to support human interface devices such as keyboard and mouse. For more information, see Human Interface Device (HID) Profile .

L2CAP (Logical Link Control and Adaptation Protocol) is a lower connection-based Bluetooth communication protocol that implements multiplexing. L2CAP does not implement flow control. It relies on a reliable device-to-device baseband link provided by Bluetooth hardware. The L2CAP layer is included in Btd.dll.

HCI (Host Controller Interface) is a basic interface to Bluetooth hardware, responsible for controller management, link establishment, and maintenance. For more information, see Host Controller Interface . The HCI layer is included in Btd.dll.

Bluetooth Universal Transport Manager (BthUniv) is an intermediate transport driver between the HCI layer ( Bluetooth transport drivers in the Bluetooth stack )and the transport layer  ( HCI Transport Layer ) . It detects the Plug and Play (PnP) device and loads the appropriate transport driver. For more information, see Supported HCI Transport Drivers . The Bluetooth Universal Transport Manager is in Bthuniv.dll.

HCI Transport Layer is a transport layer that delivers HCI commands to the Bluetooth hardware. For more information, see Bluetooth HCI Transport Layer . For more information about the modules that implement this layer, see Supported HCI Transport Drivers .

LMP (Link Manager Protocol) is the protocol that handles link establishment between Bluetooth devices, which include authentication and encryption.

BB (Baseband) enables the physical radio frequency (RF) link between Bluetooth units that form a piconet.

Each layer, with the exception of the HCI transport, is implemented as a separate entity that exposes its interfaces up and down through tables of callbacks. Each interface is well defined. There are no other interrelationships between parts of the stack; every layer is replaceable.


Host Controller Interface

The host controller interface (HCI) provides a uniform interface method for accessing Bluetooth hardware capabilities.

During the initialization sequence, the HCI creates read and write threads, establishes a connection to the Bluetooth transport, and performs a reset and read of device buffer sizes. It then enters an initialized state and is ready to accept clients.


Bluetooth HCI Transport Layer

The HCI Transport is designed to abstract and simplify physical communication between the Bluetooth stack and the controller . Microsoft Windows CE supports transport drivers for several interfaces including, UART, USB, SDIO, and BCSP.

A transport only implements a few functions; schematically, Open , Read , Write , Close and two for bookkeeping; Read and Write are blocking. The Bluetooth stack uses these functions to send Bluetooth commands and data packets, and receive data packets and events.

This interface is defined by Bt_hcip.h . The following topics discuss the HCI transport layer in more detail:


Supported HCI Transport Drivers

The following list shows some of the supported transport drivers that can be found in %_WINCEROOT%/Public/Common/Oak/Drivers/Bluetooth/Transports.

  • USB - Bthusb.dll
  • UART - Bthuart.dll
  • BCSP - Bthcsr.dll
  • Socket - Bthsc.dll
  • AmbiCom - Bthamb.dll

Windows CE also supports the transport driver for the SDIO interface.

Bluetooth Universal Transport Manager

Microsoft® Windows® CE provides the Bluetooth Universal Transport Manager (BthUniv) that is an intermediate transport driver between the HCI transport layer and Bluetooth transport drivers in the Bluetooth stack . It supports both built-in and PnP transport drivers and loads the appropriate transport driver.

Note    BthUniv always checks for PnP drivers before the built-in drivers.

BthUniv performs the following tasks:

  • Detects insertion or removal of PnP Bluetooth cards.
  • Thunks HCI transport interface calls.
  • Dynamically loads the underlying transport driver.

You can configure BthUniv though registry settings. For more information, see Bluetooth HCI Transport Driver Registry Settings .


WinCE 蓝牙协议 实现介绍:


之前没有摸过蓝牙 , 这回的项目里面有蓝牙模块 . 而我目前对蓝牙只知道的有 :1. 我们的设计里蓝牙模块是连接在串口上的 .2. 蓝牙不是蓝色的牙齿 . 呵呵 , , 我不得不提前开始接触一下蓝牙协议栈 . 粗看起来还挺复杂庞大的 . 单蓝牙组织公布的规范 1.1 多达 1084 . 先上面给出的图;东西很多 , 先分类吧 ! 从底向上看 , 蓝牙的协议和规范可以分这些大类 :

: 最底层 . 就是上图蓝色部分 . 其中有射频规范 , 基带规范和链路管理层 (Link Manager Protocol). 一个好消息是 , 不要管这部分内容 . 因为这部分都在蓝牙模块里面实现了 . 可能需要稍微了解下的就是链路管理协议主要是负责认证 , 加密 , 链路管理和控制这些功能 . 还有一些有趣的信息 , 一个主设备最大和 7 个从设备建立链接 , 从设备之间不能互通 . 主设备到从设备的最大数据传输速率为 723.2kbps, 反向 57.6kbps. 也可以配置为双向 433.9kbps.

: 接口层 . 协议栈和硬件之间的接口 . WinCE , 它也包括了 3 个部分 : 第一 ,HCI(Host Controller Interface), 第二 ,Bluetooth Universal Transport Manager, 第三 ,HCI Transport layer 主机控制接口层 . 第一层向上提供一个接口 , 第三层是和硬件的接口 , 比如连接到 Host 的是串口 , 那第三层就是一个串口的抽象的传输层 , 那为什么还需要第二层呢 ? 第二层叫统一传输管理 , 是因为 WinCE 是一个开放的平台 , 它也不知道蓝牙究竟是连接串口 ,usb ,sdio 甚至一些 pcmcia 等其他的 pnp 设备 , 等等 , 而且作为 HCI 的上层也不想知道你用什么物理接口 . 于是它抽象出来这么一个东西来统一 管理 . 简单说就是大一统所有的接口了 , 它先去扫描 PCMCIA,USB sdio pnp 设备 , 如果没有就根据注册表取默认的设备接口 . 最后被选定的接口会被安排到这里 [HKEY_LOCAL_MACHINE/Software/Microsoft/Bluetooth/HCI]


WINCE500/PUBLIC/COMMON/OAK/DRIVERS/BLUETOOTH/TRANSPORTS/ 目录下面 , 那个 univ 目录的就是 Universal Transport Manager, 其他是各个具体的 Transport layer 的实现 .

刚才说到如果没有扫描到 pnp 的蓝牙设备就使用默认的 , 这个默认的接口在哪里 ? 其实也是根据注册表来找接口 , 看看下面的内容吧 :1 代表优先级别 .name=COM2,baud=1c200, 这很明显 , 就是以 115200 的波特率打开 COM2 口了 .









细说 HCI

对于 HCI 接口 , 它向上提供了一个访问底层硬件的统一 接口 . 比如提供给 l2cap. 其实不用关心 HCI 内部怎么实现的 , 只要懂得怎么使用就可以 , 更进一步 , 如果所有应用都是在 l2cap 上的 , HCI 接口也没有必要知道 . 比如我们的应用只是基于 winsock,rfcomm, 或者 obex, 这些都是 l2cap 的上层 , 就不要关心 HCI 的上层接口 . 它是透明的 , 当它不存在好了 .

如果好奇 HCI 的上层 ( 比如 l2cap) 如何使用 hci 接口 ? 其实是使用 HCI_EstablishDeviceContext() 这个函数来获得接口 , 并注册相关回调函数和事件响应函数 . 这些模块源代码都在 WINCE500/PRIVATE/WINCEOS/COMM/BLUETOOTH/ 目录里面 .

对于一些特殊的应用 , 比如你有一些蓝牙耳机这样的应用 , 就不是通过 l2cap , 那么就要从 hci 层扩展 . 还是使用同样的接口方法 , 只是参数不同了 . 耳机这样的应用是要处理的是同步的连 接 SCO 数据包 , 于是透过参数告知 hci, sco 数据发给自己来处理 . 具体来说就是第 2 个参数 BTH_CONTROL_ROUTE_BY_LINKTYPE , 5 个参数 BT_LINK_TYPE_SCO , 以次来调用 HCI_EstablishDeviceContext().

: 协议层 . 这一层包括 L2CAP,SDP,RFCOMM. 首先要说 L2CAP, 之前已经提及这个协议 , 它建立在 HCI 上面 . 全名是逻辑链路控制和适应协议 (Logical Link Controller and Adaption Protocol) 看看它的功能 : 分发数据给更高层 , 数据包分段和重组 ... 看过 tcpip 协议栈 , 感觉这一层像 ip . 如果想基于 L2CAP 上做第 3 方扩展应用 , 就要知道如何使用 L2CAP 接口 . 其实就是使用 L2CAP_EstablishDeviceContext() 来获得 L2CAP 层的接口 , 这是不是和 HCI 的接口太像了呢 ? 接下来是 SDP, 这是一个服务发现协议 (service discovery protocol) 蓝牙设备是要组网的 , 就是用这个协议来寻找和定位其他蓝牙 设备 . 另外一个 RFCOMM 是模拟串口协议 , ETSI TS07.10 标准的子集 . 没有听过这个标准 . 反正 , 这个模块的作用是使得上层就像操作串口一样使用蓝牙 .

     蓝牙协议栈的实体究竟在哪里 ?WinCE 实现了 2 个动态链接库来实现 , 一个是 btd.dll 另外一个是 btdrt.dll ,由 device.exe 加载。 btd.dll 包含了协议栈各个层,而 btdrt.dll 提供了一组 api 来访问各个层 .btdrt.dll 其实是一个 runtime

: 应用层 . 摘抄一段 :

蓝芽协议栈的最上部是各种应用模型( Profile )。其中较典型的有服务发现 Service Discovery Application ),互通( Intercom ),无绳电话( Cordless Telephony ),传真( FAX ),拨号网络( Dial-up Networking ),耳机( Headset ),局域网访问( LAN Access ),文件传输( File Transfer ),同步( Synchronization ), Object Push 等。各种 Profile 从协议栈中选取不同的协议组合来完 成特定的功能。 下面列出各种 Profile 需要的协议组合,协议排列顺序按照从上到下的顺序: 服务发现( Service Discovery Application ),包括 SDP L2CAP LMP Baseband 互通( Intercom ),无绳电话( Cordless Telephony ),包括 TCS SDP L2CAP LMP Baseband ;传真( FAX ),拨号网络( Dial-up Networking ),耳机( Headset ),包括 SDP/RFCOMM L2CAP LMP Baseband 局域网访问( LAN Access ),包括 TCP/IP PPP SDP/RFCOMM L2CAP LMP Baseband 文件传输( File Transfer ),同步( Synchronization ), Object Push ,含 OBEX SDP/RFCOMM L2CAP LMP Baseband


WinCE 蓝牙应用 的实现 -- 蓝牙耳机:


蓝牙耳机功能 , 也就是 bluetooth headset /headfree profile, 实现起来比想象的复杂 . 早期的蓝牙规范只定义了 headset profile, headset 的实现原理是在 hci 层之上扩展一个接口 , 传输 sco 面向连接的同步音频数据包 . 限定音频流只能是单声道 8k 的话音级别的 pcm. 随着需求发展 , 明显已经不能满足了 , 于是又补充了 a2dp 协议 ,a2dp 协议在 l2cap 上层 , 使用 sbc 压缩并使用 acl 异步数据包传输 , 可以支持 cd 级别的音频流 . 但是 wince5 并不支持 a2dp, wince6 才有 . 上面 2 种都是透过 hci 层来传送音频流 , 这意味着还要受到 hci 总线带宽的限制 .hci 接口常见的有 uart,spi,usb. 为了突破这个限制 , 有一些设备会使用独立的 pcm 总线来传音频流 . 比如 csr 的芯片就有独立的 pcm 总线 . 我们的设计中 , 将蓝牙芯片的 pcm 接到了音频芯片的 pcm, 这提供了最大的灵活性 .

如果你想实现 headset, 那么就要使用 AG(audio gateway) 服务 btagsvc.dll, 并且创建一个蓝牙音频驱动 btscosnd.dll. 在你的应用中使用 DeviceIoControl 发送 IOCTL_AG_OPEN_AUDIO AG 服务 , 继而 ,AG 服务会建立 sco 连接并使用 waveOutMessage() 发送 WODM_BT_SCO_AUDIO_CONTROL 给蓝牙音频驱动 . 蓝牙音频驱动于是建立了对 hci 层的连接 , 透过参数告知 hci 要处理的是 sco 数据 , 最后创建了一个线程处理 sco 的事件 .

这个过程不会很顺利 , 一般会遇到一些问题 . 尤其是自己板上已经有另外一个音频设 备的时候 . google 中搜索你会体会到很多人在解决这个坎坷的问题 . 哪些问题呢 ? 假设板载的音频设备是 device0, 在透过 wave api 来使用驱动时候 , 希望使用 device1, 却无法成功 . 这个问题是微软造成的 . 上面提到 AG 会使用 waveOutMessage 发消息给音频驱动 ,waveOutMessage 的发送对象竟然是固定的 0. 也就是 device0. 所以这限制蓝牙音频驱动必须是 device0. 如何决定谁成为 device0 ? 并不是注册表中的 Index , 那只是决定了 WAV0 还是 WAV1. 答案是 order . 因此 , 本质就是 , 第一个被加载的音频驱动才是 device0.

通过以上方法 , 成功在 wince5 上实现了蓝牙 headset profile. 但是音质的确不很满意 .







什么是“ profiles ”:已经被标准化的 services 被称为 “profiles”; 例 如: FTP,DUN,A2DP 等。每一种 service 由唯一的 GUID 所标识;标准化的 services 就是蓝牙的 profiles protocols 。 用户可以按照需要扩展自己的 services


定义 Profiles 的目的就是定义一些标准规则,这些规则指导具体的 services 实现;这样就大大降低了不同厂商蓝牙设备之间的误操作。

The profiles have been developed in order to describe how implementations of user models are to be accomplished . The user models describe a number of user scenarios where Bluetooth performs the radio transmission. A profile can be described as a vertical slice through the protocol stack. It defines options in each protocol that are mandatory for the profile. It also defines parameter ranges for each protocol. The profile concept is used to decrease the risk of interoperability problems between different manufacturers' products.  

Bluetooth Profile Dependencies:

(56459 bytes)

  The Bluetooth profile structure and the dependencies of the profiles are depicted above. A profile is dependent upon another profile if it re-uses parts of that profile, by implicitly or explicitly referencing it. Dependency is illustrated in the figure: a profile has dependencies on the profile(s) in which it is contained ?directly and indirectly. For example, the Object Push profile is dependent on Generic Object Exchange, Serial Port, and Generic Access profiles

By using various protocols and profiles, Bluetooth can be implemented to perform the following tasks:

  • Connect to a modem through a cellular phone.
  • Connect to a local area network (LAN) access point.
  • Connect to a personal area network (PAN).
  • Connect to a wireless keyboard or mouse.
  • Connect to a wireless headset or a hands-free device.

OS Design Information

The following table shows the operating system design information for Bluetooth.

Concept Description
Dependencies None.
Hardware considerations Bluetooth interface (USB, UART, BCSP, SDIO, SC, and Ambicom).

The following table shows the components and modules that implement the Bluetooth technology in Windows CE.

Item Module Component
Libraries btd hci, l2cap, sdp, rfcomm, portemu, tdi, sys, univ, btpan
  btdrt sdpuser, bthns
Transport drivers btsdio, bthusb, bthamb, bthuart, bthsc, bthcsr, bthuniv None.
Bluetooth serial drivers sio950, wendyser, wcestreambt None.
Bluetooth Gateway Configuration Utility btgw and btconfig if the OS design includes the Web Server (HTTPD) None.
Bluetooth profiles btagsvc, btmodem, bthhid bthidsvc, hidparse, kbdhid, conshid

个人分类: Bluetooth
想对作者说点什么? 我来说一句


2013年03月25日 188KB 下载


2009年02月19日 1.91MB 下载