Our examination of the profiles begins with two that we call the generic profiles because they are fundamental to Bluetooth wireless communication. The generic access profile, or GAP, is the basis for all other profiles. It describes the fundamental operations necessary for two Bluetooth devices to establish communication, including the discovery of devices, link establishment and configuration and security considerations. The GAP is tightly coupled with the group of Bluetooth transport protocols described in Chapters 6 and Chapters 7. The service discovery application profile, or SDAP, describes fundamental operations necessary for service discovery, an operation often performed soon after a communication link is established. The SDAP maps directly to the service discovery protocol (SDP) described in Chapter 8.
Most Bluetooth devices are not expected to implement all of the profiles. A data access point, for example, probably would not implement telephony profiles, while a headset device is unlikely to implement networking profiles. However, nearly all devices are expected to implement both the GAP and SDAP; in fact, it is mandatory for all devices to comply with the GAP. Also, the use of SDP over the group of Bluetooth transport protocols follows the corresponding guidelines outlined in SDAP. These two profiles do not describe a specific usage case per se but rather define basic functions that are necessary (or at least highly desirable) for all devices.
The relationship between these two profiles may not be evident upon a cursory examination of the specification. Each deals with considerations that are mostly relevant to different layers of the protocol stack. The GAP largely addresses lower-layer protocols involved in the most basic Bluetooth communication functions, while the SDAP focuses primarily on items of interest to higher-layer applications. However, these two profiles also share many traits.
Neither the GAP nor the SDAP addresses a specific usage case. Many of the other profiles, like synchronization or cordless telephony, deal with specific, concrete end-user scenarios. For the most part, the topics covered in the GAP and SDAP are not visible to an end user (with some of the application interactions excepted), but these profiles define procedures and protocol usage that are necessary to accomplish all of the other profiles. Indeed, this is why the GAP is the basis for all other profiles and why its inclusion in Bluetooth devices is mandatory. Similarly, the SDAP defines methods for exercising protocols for the purpose of service discovery, and service discovery is a component of nearly all of the other profiles. In some respects, the GAP and SDAP both define "invisible" operations that are necessary for all other profiles and thus enable those other profiles.
Even though the GAP and SDAP are concerned primarily with low-level communication functions, each also has an application facet and thus some degree of visibility to an end user. While much of the interaction these profiles specify can occur in an automated fashion, mostly hidden from the user, some operations might involve the end user as well. Examples include "browsing" applications[1] that present information about devices and services within proximity, and the presentation to the user of various options available, such as the degree of security to be used for a particular communication link. In such cases a user interface or application programming interface could be associated with these profiles. Nevertheless, the device and service discovery and connection management is always performed in accordance with the specifications of the GAP and SDAP.
The overall profile creation process started late in the development of the specification, when it was realized that application interoperability could be best achieved through a formally specified way to facilitate it. Moreover, the GAP and SDAP were the last profiles to start being developed. The reason for their late start is that they both establish a basis for all other profiles, and hence their need became apparent only after common patterns emerged within the other profiles. The SIG realized that the Bluetooth community would be served better if these common patterns and procedures were grouped into separate documents for ease of reference. This reasoning led to the development of the serial port and object exchange profiles as well. More details on the development of the generic profiles are given within each profile presentation, starting with the GAP discussion that follows.
The Generic Access Profile, or GAP, forms a common basis for all Bluetooth profiles and hence for the common interoperable usage of the group of Bluetooth transport protocols. One of its important contributions is its definition of a standard set of terminology. Chapter 8 of the GAP contains four pages of standard terms with crisp definitions. Having this common vocabulary helps to remove ambiguity in all of the profiles, which is a key element in enabling interoperable implementations-and interoperability is the overarching goal of the profiles in the first place.
With this common terminology in place, most of the GAP is devoted to defining the procedures necessary to establish Bluetooth connections. This includes device and name discovery, inquiry procedures, pairing and bonding (explained below), and link, channel and connection establishment. For all of these considerations, the GAP provides common and standard procedures, in some cases including flowcharts. The importance of defining the fundamental communication operations cannot be overstated: without well-defined, interoperable methods for basic communication between devices, none of the other profiles could be realized.
Because the GAP is the root of all of the profiles, it is natural to assume that it was the first profile developed. In fact, the opposite is true: it was one of the last to be defined by the SIG. To understand why, one must understand the history of profile development in the SIG.
As described in Chapter 1, the SIG's software working group was organized into task forces that focused on developing one protocol or a set of related protocols. In January 1999 the topic of profiles was first discussed in depth within the SIG. Profiles were suggested, and later adopted, as a means to formalize the Bluetooth usage scenarios and to ensure interoperability among multiple implementations of the protocol stack. Thus the initial set of profiles was based upon the same usage cases that drove the marketing requirements document, which in turn drove the development of the protocols. The responsibility for developing the profiles initially fell to the same task forces that developed the corresponding protocols. For example, the headset and cordless telephony profiles were developed by those who defined the TCS-BIN protocol; the serial port profile was written by the same people who defined RFCOMM; and the object push and synchronization profiles were developed by the group that specified the IrDA interoperability protocols. Later the SIG formed an interoperability working group, separate from the software working group, to focus exclusively on the profiles and related issues, although the participants in the interoperability working group in many cases were still those who helped to develop protocols in the software working group.
In the months preceding the creation of the interoperability working group and the efforts to develop usage-scenario-oriented profiles, an activity began within the software working group to develop standardized man-machine interfaces (MMI). An MMI task force, chaired by author Bisdikian, was formed in November 1998. Its goal was to enhance the user experience and interaction with Bluetooth devices through standardized usage and connectivity procedures, nomenclature, and graphic user interfaces (where appropriate), following the paradigm of GSM cellular phones. However, the variety of devices that could be capable of Bluetooth wireless connectivity far exceeds the variety of GSM phones; hence the SIG realized that the development of standardized procedures for all conceivable Bluetooth devices could be too restrictive. Thus, with the creation of the interoperability working group, the activities in the MMI task force merged with those of the interoperability group.
As the initial set of profiles progressed and matured, it became evident that each of the profiles made assumptions about underlying transport protocol layers. Because there was no end-user scenario that dealt specifically with low-level communication issues it was not initially evident that a profile was needed to address those topics. Meanwhile the SIG had begun to discuss security issues in earnest. These two developments resulted in the realization by the SIG that a profile was needed to address the common communication elements. By May 1999 the framework of the generic access profile was in place. Considering that the specification was published the following July, it should be evident that a great deal of work was required in a short amount of time to complete the GAP.
The GAP is concerned principally with three items: dictionary, connectivity, and personalization. The dictionary consists of a collection of terms and their definitions. These terms appear in the specification, both in its core and profile parts, and the dictionary provides the foundation for their unambiguous use throughout the specification. Connectivity consists of the operations performed by devices that allow them to connect, or not, and authenticate, or not, with other devices. Personalization consists of the elements that identify and customize Bluetooth devices, like their user-friendly names and PINs. For the last two items, the GAP provides terms that can be exposed at the user-interface (UI) level, whenever applicable.
This chapter focuses on the connectivity aspects of the GAP, which are used by all other profiles. They include the connectivity modes, the security modes, and idle mode procedures. The GAP also has a section on link establishment procedures that summarizes the sequence of operations used to establish Bluetooth links and L2CAP channels; these procedures are highlighted in Chapters 6 and 7 and thus are not discussed further here.
As described in the baseband portion of Chapter 6, a device may enter inquiry scan mode or page scan mode, either to be discovered by other devices that transmit inquiries or to be connected with other devices that transmit pages to the device, respectively. The baseband specification does not state the conditions under which a device performs inquiry and page scans and thus it does not specify when a device allows itself to be discovered or connected. The HCI specification, described in Chapter 7, includes HCI commands sent by a host to the host controller, and from there to the link manager and link controller, that instruct the latter to enter the various inquiry and page states. Thus, it becomes a matter of a user-level (or, more generally, application-level) defined policy as to when a device enters any of these states. Similarly, a user-level defined policy also determines whether or not devices shall pair (authenticate) with each other. This is an important point: user-level decisions determine the degree to which a given device can be discovered, connected to and paired. One concern often expressed about Bluetooth technology is that all Bluetooth devices will automatically communicate with each other at any time, but this is a misconception. Users, or user-level applications, set the connectivity policies that determine which devices can communicate with each other, and when. These policies could be fixed by the manufacturers of Bluetooth devices or could be configurable by their users. Thus, device manufacturers could use the connectivity policies as a way to differentiate their products.
The GAP defines the policies for device communication establishment and categorizes them into discoverability modes, connectability modes and pairing modes.
A Bluetooth device is said to be discoverable if it allows itself to be discovered by other Bluetooth devices. In particular, a discoverable device executes inquiry scans regularly and responds to inquiries sent by inquiring devices. There are three levels of device discoverability:
General discoverable mode: . At this discoverability level, a device enters inquiry scans using the general inquiry access code (GIAC), which is the inquiry access code (IAC) generated from the specially reserved lower address part (LAP) '0x9E8B33' of the 48-bit Bluetooth address, as described in Chapter 6. In this mode, a device responds to all inquiries and thus it always can be discovered by all other inquiring devices.
Limited discoverable mode: . At this discoverability level, a device enters inquiry scans using the limited inquiry access code (LIAC), which is the IAC generated from the specially reserved LAP `0x9E8B00'. In this mode, a device may respond only to the inquiries that contain the LIAC and thus it may be discovered only by other devices inquiring using the LIAC.
Nondiscoverable mode: . At this discoverability level, a device does not respond to inquiries and thus other Bluetooth devices cannot discover it.
When a device is discoverable, it must always enter the general discoverable mode, even if it enters the limited discoverable mode. The latter mode may be entered in parallel with or sequentially to the general discoverability mode, as described in Chapter 6. A discoverable device must enter inquiry scans no less frequently than every 2.56 seconds and must remain in inquiry scan for at least 10.625 milliseconds.
A Bluetooth device is said to be connectable if it allows itself to create Bluetooth links with other devices. In particular, a connectable device executes page scans regularly and responds to pages sent to it by paging devices.
A nonconnectable device does not respond to pages and thus it cannot create links with other devices.
The discoverability and connectability modes might be set independently of each other[2]; however, a device that is only discoverable and not connectable may not be very useful.
A Bluetooth device is said to be pairable if it allows itself to be authenticated by another Bluetooth device, meaning that it can play the role of a claimant during an authentication transaction. Furthermore, a pairable device, in addition to accepting LMP_au_rand PDUs, must accept an initial authentication request received from a verifier in an LMP_in_rand PDU, as discussed in the LMP section of Chapter 6.
A nonpairable device responds to an LMP_in_rand PDU with an LMP_not_accepted PDU, signifying that the device is not willing to pair with any new devices.
Security operations in Bluetooth devices ultimately relate to device authentication and possibly link encryption. Recall that the former is a mandatory feature of Bluetooth devices while the latter is not.[3] Three levels of security relate to the "depth" of the security safeguards imposed upon communicating devices:
Security mode 1: . A device that operates in this mode does not have any security barrier. In particular, it never acts as a verifier and thus never sends LMP_in_rand or LMP_au_rand PDUs.
Security mode 2: . A device that operates in this mode places a security barrier at the L2CAP layer. In particular, it does not initiate any security transaction prior to receiving a request to establish an L2CAP channel using the L2CAP_Connection_Request signaling command, as described in the L2CAP section of Chapter 7. This security mode allows a flexible security model for Bluetooth devices in which security barriers in a remote device can be raised based upon the particular service that a local device requests from the remote device.
Security mode 3: . A device that operates in this mode places a security barrier at the link manager layer. In particular, it does not initiate data communications involving the upper transport and higher layers prior to authenticating the device with which it is to communicate. In other words, authentication occurs before the transmission and receipt of the LMP_setup_complete PDU, as discussed in the LMP section of Chapter 6.
Note that a device may be in one and only one security mode at any given time. For example, a device in security mode 3 cannot authenticate other devices selectively; instead it authenticates all devices that attempt to establish a link with it. A flexible security architecture for Bluetooth devices is described in [Muller99]. It forms the basis for the security modes included in the GAP.
While the connectivity and security modes are associated with activities that a Bluetooth device follows to react to incoming stimuli (such as inquiries, pages, L2CAP_Connection_Requests, and so on), the idle mode procedures relate to the device that sends the stimuli. These procedures include general and limited inquiry, name and device discovery and bonding.
The general and limited inquiries are used to discover devices in general or limited discoverable mode, respectively. The device discovery process returns, among other things, the user-friendly name of discoverable and connectable devices. Note that requesting the name could involve just the LMP layers in two devices without involving the hosts.
Bonding is a pairing procedure executed for the purpose of creating a link key between devices and storing that key for future use. In general bonding, bonding is combined with additional communications such as accessing higher-layer services. In dedicated bonding, a device connects with a pairable device with the sole purpose of creating a bond between the devices without involving upper-layer transactions.
The GAP concludes with a brief description of a service discovery procedure used to search for services supported in remote devices. This procedure follows the guidelines for service discovery found in the SDAP, which is presented next.
As noted in Chapter 8, service discovery is expected to be a key component of most Bluetooth applications. Nearly all of the profiles include a service discovery element. Like the GAP, the Service Discovery Application Profile, or SDAP, provides a common and standard method for performing service discovery using the Bluetooth protocol stack.
Unlike most other profiles, the SDAP describes a standard service discovery application model and also defines abstractions of service primitives that in some respects resemble application programming interfaces (APIs). Even though the SDAP deals with the SDP middleware layer protocol and thus addresses some of the "invisible" operations described earlier, it is aimed primarily at application writers. It is the only profile with "application" in its title and the only profile to suggest API-like primitives. As explained in Chapter 8, these primitives could be mapped to platform APIs in a straightforward manner.
Both authors have a special interest in the SDAP. Author Bisdikian served as editor of the SDAP portion of the specification, conceived the original idea for the SDAP and contributed most of its content, and author Miller chaired the service discovery task force responsible for delivering the SDAP.
As with the GAP, the need for an SDAP was not originally evident, and thus the SDAP was also developed late in the specification cycle. Not until January 1999, when most profiles were already underway, was the question raised regarding whether or not a service discovery profile was needed. By March of that year the idea of an application profile for service discovery was accepted and the SDAP development proceeded.
The development of the SDAP is rooted in the fundamental assumptions that led to the formation of the SIG itself: the diversity and number of devices that would be capable of Bluetooth wireless communication and the diversity and number of services available through these devices would steadily increase. To keep a semblance of order in the expected sea of devices and services available to a user, it was recognized that a standardized procedure should be created that would allow the user of a device to locate and identify services.
The SDAP does not describe how the service discovery itself is performed; it relies on SDP for this task. Rather, SDAP describes how an application that uses SDP should be created and should behave. In particular, it defines the functional characteristics of such an application through a set of service primitive abstractions, detailed below. Furthermore, the SDAP defines how other profiles and applications in general must use the group of Bluetooth transport protocols to carry SDP_PDUs when they need to execute SDP transactions. This latter item was an expansion of the SDAP's original scope. All of the "nongeneric" profiles contain an SDP section that provides a list of parameters for the protocol stack that leads to the particular application covered by the profile. These protocol stack parameters include ones like the RFCOMM data link connection identifier (DLCI) needed to reach, say, the PPP layer in the LAN access profile. These parameters are carried as service attributes within SDP_PDUs. However, these other profiles do not specify how the SDP layer could use the group of Bluetooth transport protocols to carry these SDP_PDUs. Since the latter process should be identical for all profiles, one idea was to include it in a generic profile like the GAP. However, the GAP does not focus on the transport of data with a source or sink above the L2CAP layer. Moreover, the SDP specification itself does not contain the dependencies of SDP on the group of Bluetooth transport protocols. Even though this may seem like an oversight, it was a deliberate choice. The Bluetooth service discovery protocol, although tied to systems that utilize Bluetooth wireless communication, is in principle a transport-independent protocol. Hence, the SDP specification focuses exclusively on the SDP transactions themselves and the various SDP_PDUs that are used, as well as the type and form of information that is carried in them. The SDP specification does not particularly focus on how these transactions are carried over the Bluetooth air-interface. Ultimately, SDAP became the only (and natural) point of reference for describing how the SDP layers use the group of Bluetooth transport protocols to carry the SDP_PDUs to each other.
The SDAP is unique among the application-oriented profiles, like the file transfer profile, the LAN access profile, and so on. These other profiles describe how the complementary parts of a user-level application running on two (or more) devices work together to support a particular usage scenario. The application in SDAP needs to be present in only one device. This application interacts with the SDP layer of the stack in the device where it resides to initiate SDP interactions with one or more SDP layers in other devices, so as to learn about services in those other devices. Upon the arrival of responses from the other devices, the service discovery application can make those results available to the user of the device that initiated the transaction(s).
Often, service discovery in non-Bluetooth environments is performed by broadcasting inquiries for services or inquiries for locating directories of services. In the latter case, when a service directory is found, it is then contacted to find out about services that are registered there. In a Bluetooth piconet, broadcasts are entirely unidirectional in that they are exclusively directed from the master to the slaves of the piconet. Furthermore, broadcast transmissions are not recoverable in that they cannot be retransmitted following an error in their transmission. Thus, service discovery in a Bluetooth piconet does not use a broadcast model. Service discovery in Bluetooth piconets is closely associated with device discovery. Service discovery is executed only between fully identified pairs of devices and only after they have discovered each other and have created a Bluetooth link (up to and including an L2CAP connection) between them.
According to the SDAP, devices participating in service discovery may have either of the following roles:
Local device: . This device implements the service discovery application, like the service browsing application referred to in Chapter 8. It also implements the client portion of the SDP layer. A local device initiates SDP transactions as shown in Figure 8.3.
Remote device: . This device is contacted by a local device to inquire about services. A remote device implements the server portion of the SDP layer. It responds to SDP transaction requests from a local device. To produce its responses, the remote device maintains, explicitly or implicitly, a database[4] that contains service records for the services available via the remote device.
Even though some devices may act only as local or as remote devices, these device roles are, in general, temporary and meaningful only when an SDP transaction between two devices is under way. A device can be a local or remote device at different times or even at the same time, depending upon when it creates service inquiries or responds to them. The SDAP device roles bear no relation to the baseband roles of master and slave, as the latter roles are meaningless above the link manager layer. A local device could be either a master or a slave in its piconet, as could a remote device.[5]
The SDAP is the only profile that uses the term application in its title. However, the SDAP does not define any particular application. Such a definition would be very much platform dependent and possibly too restrictive for application developers, neither of which is a desirable objective for a specification. However, the SDAP specifies the services that a service discovery application should provide to its users to be useful. These services are summarized in four service primitive abstractions. These primitives could be mapped to an appropriate set of APIs based upon the underlying software and/or hardware platform in which an SDAP application is instantiated. An example mapping of these primitives to the Salutation APIs is given in [Miller99]. These primitives are:
serviceBrowse: . This service primitive is utilized when a local device wants to perform general service searches, referred to in Chapter 8 as service browsing. These searches might take the form of queries about what services in general or what services of type S are available, if any, via a selected set of remote devices. This application-level service primitive results in SDP_PDU transactions initiated by any one of the three basic request SDP_PDUs presented in Chapter 8: SDP_ServiceSearchRequest, SDP_ServiceAttributeRequest, or SDP_ServiceSearchAttributeRequest. Optionally, the LMP_name_request PDU could also be sent to learn the user-friendly name of the remote device.
serviceSearch: . This service primitive is utilized when a local device wants to perform searches for a specific type of service. The search could take the form of queries about what services of type S with attributes A1 and A2 are available, if any, via a selected set of remote devices. Similar to the previous primitive, this application-level service primitive results in SDP_PDU transactions initiated by any one of the three basic request SDP_PDUs previously mentioned.
enumerateRemDev: . This service primitive is used when a local device wants to search for remote devices in its vicinity. The search can be restricted with a class of device (CoD) qualifier to search only for devices belonging to the specified class. This application-level service primitive results in the local device executing inquiries to learn about devices, primarily any new devices, in its vicinity. If, in the future, CoD-specific dedicated inquiry access codes (DIACs) are standardized, then the inquiries for this primitive could be generated according to these DIACs. Otherwise, the generic inquiry access code (GIAC) is used and the local device needs to filter the received responses according to the information included in the CoD field in the FHS BB_PDUs received from the responding devices.
terminatePrimitive: . This service primitive results in the termination of the operations invoked by the previous primitives.
The first and second primitives above relate directly to transactions involving SDP_PDUs. The third primitive could be satisfied merely by requesting that the device enter the inquiry mode with the sole purpose of searching for any other devices in the inquiry scan state (as described in the baseband section of Chapter 6). The last primitive simply terminates any ongoing actions resulting from the use of any of the other primitives.
The SDAP requirements on the Bluetooth stack are straightforward. To implement this profile one needs to use nothing beyond the default settings for all the protocol layers below the SDP layer. In particular, devices that connect for the sole purpose of performing service discovery do not need to authenticate each other or encrypt their Bluetooth link.[6] The SDP transactions are carried over the ACL baseband link between the devices. At the L2CAP layer SDP transactions are carried over connection-oriented channels configured to carry "best effort" traffic.
An additional distinction of this profile is that it identifies the conditions under which L2CAP channels carrying SDP traffic are torn down. This is so because SDP does not define a session or a transport protocol for carrying SDP_PDUs. SDP itself is in essence a connectionless protocol. To run the connectionless SDP request/response transactions, the L2CAP layer needs to maintain the L2CAP channel that carries the transactions at least for the duration of the transaction. For efficient use of the transmission resources, the L2CAP channel between an SDP client and an SDP server should be maintained even longer. Ultimately, it is the application on behalf of which SDP transactions are executed that should open and maintain, for as long as necessary, the L2CAP channel for SDP transactions between two devices.
In this chapter we have highlighted the two generic Bluetooth profiles: the GAP and the SDAP. The GAP describes the connectivity and security modes of operation for a device that permits it to discover, be discovered by, and create trust bonds and Bluetooth links with other devices. These modes of operation are user- (or application-) settable device policies that specify how the device should wbehave relative to other devices with which Bluetooth communication might ensue.
The SDAP describes the functional characteristics of a service discovery application. Furthermore, and equally importantly, the SDAP describes the way that the SDP layer must use the group of Bluetooth transport protocols to carry SDP transactions. This aspect of the SDAP also forms the basis for executing service discovery within the other profiles.
[2] There is a host controller interface command that enables inquiry and page scans independently of each other.
[3] However, some profiles do mandate support for and the use of encryption.
[4] The specification does not define the format of this database, leaving that choice to implementers. Moreover, this need not be a "database" in the classic sense; it is simply a collection of information maintained by the SDP server in a format suitable for the device.
[5] Often a local device acts as master of a piconet, since typically it would be the device that desires to create connections with other devices and search for and use services on them. However, this does not mean that a local device must be a master to perform service inquiries. A slave device could equally well initiate such inquiries.
[6] This does not imply that device authentication and/or link encryption should not be performed. This statement simply implies that the SDAP imposes no security precautions for its execution. Security is as much a usage scenario requirement as a user-level settable policy, as discussed in the GAP. Security precautions may still be taken for reasons outside the scope of SDAP.