Establishing Connections through HCI (Windows Embedded CE 6.0)


After loading the protocol layer, it calls the HCI_EstablishDeviceContext function for registration. The call to HCI_EstablishDeviceContext establishes a connection to the HCI layer.

The following code example shows the HCI_EstablishDeviceContext function declaration.

int HCI_EstablishDeviceContext(
   void*                  pUserContext,       /* IN */
   UINT                   uiControl,           /* IN */
   BD_ADDR*               pba,                /* IN */
   UINT                   class_of_device,     /* IN */
   UCHAR                  link_type,           /* IN */
   HCI_EVENT_INDICATION*  pInd,               /* IN */
   HCI_CALLBACKS*         pCall,              /* IN */
   HCI_INTERFACE*         pInt,               /* OUT */
   in*t                   pcDataHeaders,      /* OUT */
   int*                   pcDataTrailers,     /* OUT */
   HANDLE*                phDeviceContext     /* OUT */

HCI_EstablishDeviceContext supplies a table of HCI events and HCI callbacks by passing pointers to HCI_EVENT_INDICATION and HCI_CALLBACKS structures, respectively. The upper layer receives a function table for the HCI layer interface in a pointer to the HCI_INTERFACE structure. For more information about HCI_INTERFACE, see HCI Commands.

In the call to HCI_EstablishDeviceContext, set the packet routing option by specifying a flag in the uiControl parameter. The following table shows the available packet routing options.

Flag option Description


This option is typically reserved for the default handler such as the L2CAP stack. Only one stack can register to accept all the notifications.

A notification is passed up to this stack if there are no other stacks registered for this event.


Use this option to route all local device control packets here.

This is used for local device control, that is, place a device into a particular operating mode, one can register for this access, use this callback to program the device, and then deregister.

Only one client at a time is allowed.

This option is typically used for management layers that do not accept incoming connections at all. There may be more than one of these.


Use this option to route all security events up this stack including PIN requests. This is used to implement the security manager.

With this option, link key/PIN requests for all connections will be forwarded to this stack layer. Only one stack is allowed to be handled for security events.


This option routes all callbacks associated with a particular device up this stack. Only one client is allowed for each BD_ADDR structure.


Use this option to route connection requests associated with this class of device (COD) up this stack. Only one client is allowed for each COD.


Use this option to route connection requests associated with this link type up this stack. This is used to implement SCO connections.

A sample SCO connection scenario includes registering for a particular Bluetooth device, processing all SCO data packets here, and then returning all L2CAP packets to the L2CAP layer.

The extension layer can choose to listen to all, or selected types, of events. For example, if you want the stack to accept only connections from a specified device, set uiControl to BTH_CONTROL_ROUTE_BY_ADDR and specify the Bluetooth device as a single pointer to the device address in the pba parameter.

You can also configure the extension layer to accept only synchronous connection-oriented ( SCO) connections, set uiControl to BTH_CONTROL_ROUTE_BY_LINKTYPE and specify the appropriate link type in the link_type parameter. The same process applies to the class of the device.

If the connection is established, a pointer to the device context handle is returned in the phDeviceContext out parameter. To close the connection, pass this handle in the HCI_CloseDeviceContext function.

Community Additions