Bluetooth Profiles is concerned primarily with the development of Bluetooth specific applications, which in turn encompass the requirements as defined by the Specification of the Bluetooth System: Profiles, v1.1. Bluetooth applications in their infancy were injected into public view and subject to immediate expectations. For Bluetooth technology to become a viable wireless solution, we had to move from the wonder and mini-celebrations ^[1] that were invoked when we all initially created our first successful connections. At various stages of development, numerous emotions were experienced. We were able to progress from creating our first connection to performing a file transfer over an emulated serial port, using a legacy application; then came synchronisation and so on. Yet, in our peripheral vision, we gained a glimpse of the sales and marketing team constantly pressing us with numerous questions—when will it be ready?, when will it jump through this hoop?, and when will it perform that triple-summersault? In essence, we were not developing Bluetooth applications fast enough. Indeed, the Bluetooth marketing machine began chugging away long before the first products were anywhere near release, resulting in a seemingly endless wait for the promised revolution to arrive. An enormous amount of frustration was inevitable for all concerned, as issues of core functionality were thrashed out in the boardrooms of manufacturers around the globe. This resulted in the underlying tone of Bluetooth promotion resting, to a greater extent, upon the software and hardware embodiment of the products rather than on the users’ experience of utilising Bluetooth technology. Increasingly, however, these experiential elements are being viewed as a primary route for achieving critical mass and, as a result, the public is finally beginning to open up to the possibilities of a wireless world.

Figure 1-1 illustrates the psychological elements of the buying process that hold particular value to future Bluetooth developers; here, we can view the progression from a positive buyer experience to a new promotional message as a cycle of user-oriented market growth. Indeed, if we gain nothing else from reviewing the Bluetooth market, we should, at the very least, reinforce within ourselves the importance, from a development perspective, of seriously applying real-world usage potential to future Bluetooth products.

Figure 1-1. The psychological elements of the buying process that hold particular value to future Bluetooth developers. The process is cyclical, where positive feedback re-enters the promotional message.

The promotional drive of Bluetooth technology, to date, has naturally taken the traditional routes of press, collateral and event opportunities through conferences and, of course, the ever-popular Unplugfests; but the best promotion of potential Bluetooth applications will, without a doubt, emerge through the users themselves. Consumer enthusiasm toward the freedom afforded by the adoption of Bluetooth-enabled electronics will inevitably become highly contagious. At home and in the office, as with any technology, it will continue to evolve. The future will almost certainly see it become an accepted part of everyday life.

Time and time again, developers, sales, marketing and users often wonder and ask what are the Bluetooth Profiles? Profiles enable end-user functionality by defining user and behaviour characteristics. They have many defining objectives, one of which is to achieve a level of interoperability between manufacturers. In defining their functionality, certain expectations are made of the underlying Bluetooth protocol stack. Each profile defines what features of the stack are required and how they are subsequently used. In Figure 1-2, we illustrate the dependencies of all the profiles within the current specification as a hierarchal organisation. In Figure 1-3, we illustrate the components that make up a typical Bluetooth protocol stack.

Figure 1-2. An hierarchal organisation of the current profiles, illustrating the dependent profiles.

Figure 1-3. A typical structure forming the components that make up a Bluetooth protocol stack.

As an application developer, you will embody the functionality within your Bluetooth specific application and utilise the underlying capabilities of a Bluetooth protocol stack through an Application Programming Interface (API). All profiles define a set of user interface expectations and these will surface through your applications to the user. The user will become familiar with the terminology and should experience a commonality of features between the various manufacturers’ products. This is evident in the common terminology mandated by the Profiles as to what should be described to the user. In one such example, a user is prompted to enter a Bluetooth Passkey, which will be common to all products whether embedded (mobile phones, wireless modems and so on) or used in a Microsoft Windows or Linux operating system environment.

The Profiles define a minimum set of characteristics that should be inherent in all products. Manufacturers should avoid a re-education of the ‘user-population’ by adhering to the philosophy that users have already developed a relationship with the technology that surrounds them on a daily basis. The purpose of any new technology should be that of support rather than suppression.

Numerous Bluetooth products have already emerged onto the marketplace. Yet this is just the beginning of the ‘market stream,’ as both the variety of applications and rate of release are expected to grow considerably over the next few years. The products form the end-function for the user; they are the embodiment of hardware, software, manufacturing, production, sweat and tears. As such, they come in many guises: integrated or stand-alone applications on a Microsoft or Linux operating system. Alongside these, we have witnessed the release of products that are embedded: mobile phones, Personal Digital Assistants (PDAs) and cordless handsets.

With the prospect of undertaking the development of a new product, the engineer can draw upon various development suites that aid in the creation of both hardware and software. Much of the groundwork has already been covered, making it unnecessary to ‘re-invent the wheel’.

Bluetooth development kits themselves offer various levels of support—from a low- or high-level perspective. Each kit is designed to offer various benefits to the developer, obviously depending upon what you need to achieve. The primary, generic purpose of all development kits is to provide a supported core tool for the development of your new and unique Bluetooth application, aiding in your development life-cycle and certainly making life easier by allowing you rapid realisation of your product expectations. In addition to this generic primary benefit, each kit will ‘sing its own praises’ by reinforcing a number of product-specific value-added traits such as free developer seminars, access to knowledge base directories, technical training or round the clock support.

A general premise is that Host Controller Interface (HCI) or Link Manager (LM) commands are entered through a common window, which affords the developer the ability to observe a variety of operational data simultaneously. Typically, this is the minimum expectation of a development suite. Common viewable operations include protocol monitoring through the stack layers, message exchanges and the transmission and monitoring of individual commands or events, typically at the higher-layers, such as L2CAP, RFCOMM and SDP. Through this observation portal, the developer is also equipped with a powerful tool for code debugging and editing. Another key benefit to the kits is their innate teaching ability in that the kits provide an immediate professional development environment for those new to Bluetooth Profiles and wishing to understand the Bluetooth protocol in greater depth. It also demonstrates how each layer of the stack interacts with each other. By studying the readily available source code within any Bluetooth development kit, you instantly arm yourself with the confidence of a proven application template on which to evolve your individual knowledge and abilities.

Figure 1-4. The Casira development system from Cambridge Silicon Radio. (Courtesy of Cambridge Silicon Radio.)

Your development kit may come complete with a full Bluetooth protocol stack, which will be reconfigurable for different interfaces between the Bluetooth host and host controller; there will be more about this later on in this chapter. All kits are linked to a particular manufacturer’s device and, as such, there may well be some company-specific constraints surrounding the APIs needed to design an application. This does not alter the fact that, by using a development kit, much of the work has already been accomplished on your behalf. From a marketing perspective, any organisation planning to provide a Bluetooth development kit would be naïve not to consider any promotional opportunities attached to such an offering.

Many companies have invested considerable effort in developing Bluetooth protocol stack solutions, which can be purchased off the shelf or tailored for a particular project, where minimum development effort is required; numerous companies have also offered Open Source ^[2] solutions. With a solid foundation in a Software Development Kit (SDK), developers can realise their specific applications with greater speed and economic efficiency. Solutions can be tailored for Microsoft Windows or Linux-based operating systems as well as embedded platforms. In the following sections, we analyse in some more detail the relationship of the Profile and Protocol and further understand the interaction between the host and host controller.

Figure 1-5. The MTC-60180 development system from Alcatel Microelectronics. (Courtesy of Alcatel Microelectronics.)

The Profile and the Protocol

In our earlier discussion, we touched upon the purpose and objectives that the Profiles serve. In development terms, the creation of an end-function, is dependent upon the realisation of a Profile specification using the underlying protocol. The Profile addresses the characterisations by stipulating what it expects from the Bluetooth protocol stack. How that application manifests itself to the outside world is also prescribed by the requirement defined in the Profile. With an SDK, a developer may utilise the features of a Bluetooth protocol stack by addressing core functionality through an API. As a company wishing to develop Bluetooth applications, an API may have already been tailored to meet with your specific requirements. In Figure 1-6, we further illustrate the structure of the stack where an API has been imposed upon the key components, in turn exposing core functionality to the application developer.

Figure 1-6. The Bluetooth protocol stack exposes APIs throughout, where application developers utilise these interfaces to realise end-user functionality.

Using Figure 1-6 as our example illustration, APIs such as that illustrated in Table 1-3 and Table 1-4 can be used to control and manipulate core functionality at the heart of the Bluetooth protocol stack.

Table 1-3. Some typical APIs that would be used to open and close an RFCOMM connection as well as transmit and receive data over the connection.

API	DESCRIPTION
RFCOMM_OpenConnection	An API function that would be used to open or create a communications link with the peer device.
RFCOMM_CloseConnection	An API function that would be used to close or disconnect a communications link with the peer device.
RFCOMM_TxData	An API function that would be used to transmit data to the peer device.
RFCOMM_RxData	An API function that would be used to receive data from the peer device.

In Table 1-3 an application may use these APIs in order to quickly establish an RFCOMM connection to its peer device; whereas Table 1-4 illustrates some possible APIs that may be used to learn of the services of devices that are in radio range.

Table 1-4. Some typical APIs that would be used to retrieve service information from a remote device.

API	DESCRIPTION
SDP_ErrorResponse	An API function, which is used to signal an incorrectly formatted request from the client.
SDP_ServiceSearchRequest SDP_ServiceSearchResponse	These APIs are used in combination to instigate a search request to identify corresponding records held within a server.
SDP_ServiceAttributeRequest SDP_ServiceAttributeResponse	These APIs are used in combination to retrieve specific attribute record information from a server.
SDP_ServiceSearchAttributeRequest SDP_ServiceSearchAttributeResponse	Finally, these APIs are used in combination to encompass both the functionality of the SDP_ServiceSearchRequest and SDP_ServiceAttributeRequest. This functionality attempts to reduce the SDP traffic when seeking specific services.

Understanding the Bluetooth Host

The Bluetooth Host is the set of protocol higher-layers provided to manipulate and control the Host Controller; we provide this illustration in Figure 1-7. This interface is controlled through the HCI and most Bluetooth development kits are exposed at this level. Conceptually, the HCI is not a layer, but forms the Hardware Abstract Layer (HAL), where any company’s host controller can be plugged into the host and work together transparently; the host can be considered hardware independent.

Figure 1-7. An implementation of a host, which forms part of the higher-layers of the Bluetooth protocol stack.

The HCI has been constructed to facilitate many transport layers to include Universal Serial Bus (USB), Universal Asynchronous Receiver/Transmitter (UART) and RS232. This provides diversity in the availability of development kits where the various applications may differ. In one such example, a USB interface may be provided for the host controller to interact with the host, where a USB dongle is inserted into a notebook device, which houses the host. A connection is established over the USB interface and the host can manipulate and control the host controller that exists on the USB dongle.

Understanding the Bluetooth Host Controller

The Bluetooth Host Controller is the set of protocol lower-layers provided to manipulate and control the radio unit; we provide this illustration in Figure 1-8. The Host Controller is controlled through the HCI, which in turn is responsible for link management and the over the air-interface.

Figure 1-8. An implementation of a host controller, which forms part of the lower-layers of the Bluetooth protocol stack.

The Bluetooth Special Interest Group (SIG) is astutely sensitive to the prominence of interoperability within the marketplace. Accordingly, all specifications are subject to intensive qualification prior to a licence for use being granted. Events such as Unplugfests hold great value, as they allow manufacturers to test the interoperability of their individual products with each other. From a marketing perspective, achieving ease of interoperability is paramount for any manufacturer’s product to succeed in the marketplace. A key tool of the Profiles is to provide a base frame structure that transcends all branding and ultimately provides the interoperability that, as developers, we depend upon in order to see our product evolve from sketchpad to shelf. The only way to ensure compatibility is to actually test against a range of reference devices. To this end, a number of test labs and tools have emerged, all pledging to make interoperability issues vanish from any proposed product specification. In the following section we discuss, in part, the qualification process, which leads to a fully qualified and compliant Bluetooth product.

Bluetooth Qualification, as its name suggests relates to the requirement that all Bluetooth products are developed in accordance with the current set of Bluetooth Specifications, as required by the Bluetooth Adopters agreement. The base establishment of the rules and procedures surrounding the qualification of a product is called the Bluetooth Qualification Programme (BQP). All guidelines and practices of the BPQ are formalised by the Bluetooth Qualification Review Board (BQRB), which in turn, is chartered by the Bluetooth SIG via the Programme Directive (PD). Promoters of the Bluetooth SIG will select delegates to join the BQRB when required to do so. The process of qualification has been devised with the developer in mind and holds strong the mission of protecting rather than of stifling its natural evolution.

In general, product qualification can be accomplished using the following steps, as laid out within the current qualification guidelines; this is also summarised in Table 1-5. In Figure 1-9, we illustrate the hierarchal delegation of the qualification programme.

Figure 1-9. The authoritative delegation for the Bluetooth Qualification Programme.