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 |
|---|---|
| BTH_CONTROL_ROUTE_ALL | 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. |
| BTH_CONTROL_DEVICEONLY | 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. |
| BTH_CONTROL_ROUTE_SECURITY | 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. |
| BTH_CONTROL_ROUTE_BY_ADDR | This option routes all callbacks associated with a particular device up this stack. Only one client is allowed for each BD_ADDR structure. |
| BTH_CONTROL_ROUTE_BY_COD | 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. |
| BTH_CONTROL_ROUTE_BY_LINKTYPE | 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.
See Also
Host Controller Interface | Bluetooth OS Design Development | Closing Connections through HCI | Bluetooth Protocol Stack
Send Feedback on this topic to the authors