The concept of a world without wires maps itself quite well onto the ultimate headset as outlined in the Headset Profile. A variety of new scenarios are introduced with this profile, some of which are illustrated in Figure 7-1. With an increasing number of ear pieces being introduced by several large well-known companies, coupled with the time [1] needed to bring prices to a more acceptable and affordable level, we will surely see these items as a fashion accessory bundled with your mobile phone handset.
Figure 7-1. The Bluetooth-enabled headset is capable of establishing a connection with a multimedia capable notebook and a mobile phone, both of which act as our audio gateways.
During the course of our discussion, a comparison of this profile is made with other similar telephony profiles, although the usage models do vary. In our first comparison, we examine the overlap between the Headset and the Car Hands-Free Profile, Chapter 17, which is introduced later in Part III, The New Profiles. We then take our earlier Cordless Telephony, Chapter 4, and Intercom Profiles, Chapter 5 and examine more closely how these devices may help one another or demonstrate where product overlap may exist.
In the Car Profiles, Chapter 17, we introduce three new profiles that are vehicle orientated. More specifically, we compare the Hands-Free Profile with the Headset, as there is some overlap between the usage models for these profiles. Each of these profiles provide audio transfer from one device to another; in the Hands-Free usage model, an in-car hands-free kit is used to provide audio transfer from an Audio Gateway (AG) to the Hands-Free (HF) unit. The user still has to manipulate the mobile phone handset (AG) to initiate, receive and terminate calls. Furthermore, the protocol structure is also similar in nature, as you can see in Figure 7-2. Both profiles use AT Command Control to facilitate control signalling and, as such, both implement a controller component: headset and hands-free, where these specific components are used to identify the layer that manages the AT command parsing.
The Headset Profile provides functionality through the use of a discreet earpiece, where limited functionality can be provided with on-board button control. In both cases Voice Recognition (VR) may also be provided to alleviate the distraction that may be imposed when operating such devices; in particular, it is important that the driver of a moving vehicle keeps his or her eyes focused on the road at all times. In comparison to a Hands-Free kit, a Headset device is overall less intrusive and easier to use (although it is assumed that the user has become familiar with the operation of the Headset product).
The Cordless Telephony profile requires the implementation of the Bluetooth Telephone Control Protocol Specification (TCS). In Figure 7-3, we compare the stack components that make up both application types, where the Bluetooth protocol stack architecture can be compared and examined in more detail. As we previously mentioned, the Cordless Telephony Profile is based upon TCS, which resides above L2CAP. As we can see from our illustration, the Headset Profile is dependent upon the implementation provided by RFCOMM. This provides the Headset with the AT Command Control and is implemented, as the name suggests, through a series of AT Commands, which enable and control signalling.
Figure 7-3. The Headset and Cordless Telephony Profiles components are placed side-by-side to illustrate the differences in the stack architecture.
In our new usage scenarios, as illustrated in Figure 7-1, the headset makes use of an AG; we will look at this role in more detail later. We can see that a headset device can equally lend itself to the role of a cordless handset, where audio transfer is made between the base station of the cordless gateway and the headset, in the same way it occurs for the cordless handset. However, it would require the headset to be compliant with the Cordless Telephony Profile, that is, have an implementation that encompasses TCS; moreover, a dual implementation of the AT Command Control and the Cordless Telephony may be considered, allowing the user to switch between usage scenarios. The implementation of this switch may be transparent, allowing the user to seamlessly move from one environment to another.
The Headset Profile mandates the use of the underlying Bluetooth audio capability, where there has to be some degree of certainty that the transport used is able to guarantee the timely delivery of the audio data. A Synchronous Connection Orientated (SCO) communications link is used to provide the best quality available through reserving channel bandwidth. Furthermore, audio coding schemes are used to provide compression and to overcome potential errors in the data transmission. The Pulse Code Modulation (PCM) has two types of logarithmic compression, these are A-law and µ-law, where either compression technique can be applied on the voice channels over the air-interface; both techniques are detailed in the International Telecommunications Union (ITU) Recommendations G.711. Continuous Variable Slope Delta (CVSD) provides the second scheme, which is particularly efficient for voice communication; it also tolerates potential errors in the audio data. Audio data can be transferred up to a data rate of 64 Kb/s, which should be sufficient for carrying voice communication. Later on in this chapter we look more specifically at the commands that are used to create an SCO connection and the various optional parameters that define the link.
This section considers both existing and future usage models through scenarios that may be typical for the Headset Profile. We begin by exploring the existing models, where audio transfer and limited remote control are provided to the headset. In future usage models, we consider other scenarios where the introduction of a headset may provide extended functionality.
At a minimum, the Headset Profile allows a user to wear an earpiece through which audio transfer from a mobile phone is made; it is also capable of providing limited remote control functionality, where it is capable of asserting call connection, termination and rejection. Other remote control capability is extended to volume settings, where the level of the volume can be set in the headset and is subsequently reflected and stored for later retrieval in the AG.
The AG device is used to initially create an Asynchronous Connectionless (ACL) connection between the two devices. The AG discovers the device and then requests whether audio transfer should be made to the HS. Upon confirming that audio transfer should be made, any subsequent incoming or outgoing calls can be heard through the HS.
In Figure 7-4, we show a typical headset product and, by the use of button presses, the user is capable of initiating, terminating and rejecting a. Further functionality is provided to allow the received volume of the device to be adjusted; the two-position rocking switch can be used to increase or decrease the volume.
The headset itself provides limited operation for making outgoing calls; currently, the last number redial is a function offered by many devices. In the Car Hands-Free Profile, Chapter 17, the introduction of VR is used to provide greater scope for making outgoing calls. Although not mandated in the profile, the use of VR is a natural step forward for a future usage model.
Furthermore, consideration should also be given to the numerous mobile phones that are currently in circulation, as a large majority of these devices do not support Bluetooth technology. So, do you pass over your existing mobile phone for a new one? Several companies offer the ability to bestow new wireless capabilities upon your non-Bluetooth mobile phone. In Figure 7-5, we illustrate a device that is capable of enabling Bluetooth wireless capability, such as the headset. It is not necessarily restricted to this usage model. Other scenarios, such as dial-up networking, fax and personal area networking can also be supported.
Figure 7-5. The device shown is capable of enabling Bluetooth applications for a mobile phone. (Courtesy of Plantronics Inc.)
In the Cordless Telephony Profile, Chapter 4, we also introduced the headset as a replacement or an addition to the usage model scenarios. In this instance, a headset may be used to allow the user to roam the office quite freely whilst remaining in contact with the cordless gateway. Similarly, VR may be used to make outgoing calls. This scenario lends itself well to an office environment with the provision of voice roaming, allowing the headset to remain connected to the cordless gateway, moving from one cordless gateway station to another. The user is then free to accept and make outgoing calls from any location within the office.
The Headset Profile provides two new roles: an AG and a HS. The HS device can be placed over the ear, where audio communication and remote control capability has been transferred to the HS from the AG. The AG and HS support full duplex audio support and in Figure 7-6 we can see how the Headset components are integrated with the existing Bluetooth protocol stack.
Figure 7-6. The core components of the Bluetooth protocol stack are shown, illustrating how the components of the Headset Profile are integrated.
The profile defines the set of protocols and procedures required to realise its implementation. Support for one SCO audio link is provided and, as such, only the two participating devices can operate at any one time. The profile mandates support for audio CODECs (see Section 7.1.3, Bluetooth Audio), where the resulting audio is monophonic and has a data rate of 64 Kb/s. The SCO connection is created after the initial ACL connection establishment has taken place.
There are no fixed master-slave roles; this leaves either device free to initiate and terminate a connection, although typically the AG will initiate the primary connection, where inquiry and device discovery procedures are undertaken. The user may determine whether authentication and/or encryption should be used between the two devices; however, if it is used, then the procedures as described for authentication and encryption in the Generic Access Profile, Chapter 2, must be adhered to.
In Figure 7-6, we illustrated the components that made up our Headset Profile. The profile is also dependent on the Serial Port Profile, Chapter 6, in its implementation. A series of AT commands are also used to enable control signalling, where AT commands are sent to the AG and the HS receives its responses. On closer inspection, you will notice that the AG device provides audio port emulation, whereas the HS provides an audio driver. It is also assumed that some management entity exists, where access to lower components of the stack is provided; in some cases a direct PCM route is used to enable faster audio throughput.
In Table 7-1, clarification is provided with regard to the roles used within the context of this profile. In general, DeviceA represents the initiating party and DeviceB represents the accepting party. The terms are often used interchangeably, when describing specific operations in various contexts and are provided here for reference.
Since the profile does not prescribe strict master-slave behaviour, either device can be responsible for an initial connection, although it is the AG that initially creates the ACL connection. This general notation is used within the course of this chapter and will always represent participating devices as the initiator or DeviceA and the acceptor or DeviceB. In the following section, the modes of operation are discussed in more detail.
Table 7-1. The list of behavioural characteristics that are typical for this profile.
|
CONFIGURATION |
ROLE |
DESCRIPTION |
|---|---|---|
|
DeviceA |
AG |
A device acting as an audio gateway, which may take the form of a mobile phone or hands-free unit. In this particular context, the device is described as initiating the connection with the accepting device. |
|
Initiator |
This configuration describes the device that instigates the original connection or the device that wishes to initiate communication over an existing link. | |
|
DeviceB |
HS |
A device that behaves as a headset, where audio transfer is made between the gateway and headset. It is also the party that accepts incoming connections from the audio gateway. The headset may also instigate a connection with an audio gateway, where the audio gateway will take on the role of acceptor. |
|
Acceptor |
This configuration describes the process of the device accepting the initiated communication from DeviceA. |
The Headset Profile is dependent upon the underlying profiles, where Connection Establishment procedures are applicable and are illustrated in the Generic Access Profile, Chapter 2. The connection establishment procedures encompass the availability of an initialised RFCOMM session, which includes the capability provided by a virtual serial connection as outlined in the Serial Port Profile, Chapter 6. If the device is in Park Mode, then the device is unparked prior to any creation of a SCO connection; if no previous session exists, then one is created and the device may request parked status. It is therefore assumed that the AG and HS devices have previously performed an inquiry, discovery and any authentication and/or encryption.
In this state, the AG device awaits a user action or an internally generated event such as an incoming call. On receiving either notification, the headset is alerted through an unsolicited RING result code (see Section 7.5.1.3.1, AT Command Control); Figure 7-7 provides further clarification of this sequence of events.
The headset is alerted to the incoming call, which now requires user intervention. At this point, the user may accept or reject the call. On pressing a button on the headset, an alert is sent to the AG device. The HS sends an AT+CKPD command as notification (see Section 7.5.1.3.1, AT Command Control). The AG is responsible for creating the SCO connection and can create a SCO connection after connection establishment.
The Headset Profile is dependent upon the underlying profiles, where Connection Establishment procedures are applicable and are illustrated in the Generic Access Profile, Chapter 2. The connection establishment procedures encompass the availability of an initialised RFCOMM session, which includes the capability provided by a virtual serial connection, as outlined in the Serial Port Profile, Chapter 6. If the device is in Park Mode, then the device is unparked prior to any creation of a SCO connection; if no previous session exists, then one is created and the device may the request parked status. It is therefore assumed that the AG and HS devices have previously performed an inquiry, discovery and any authentication and/or encryption.
The AG is always responsible for creating the SCO connection and can create a SCO connection after connection establishment. In this state, the AG device awaits a user action initiated from the HS, where the AG is altered through an AT+CKPD command (see Section 7.5.1.3.1, AT Command Control); Figure 7-8 provides further clarification of this sequence of events.
Either device may transfer an audio connection. In both cases, user intervention is required. On the HS, the user may initiate a transfer from the AG by operating a button, which would then result in a SCO connection being established with the headset. Conversely, the AG may transfer audio from the HS by operating a function from the AG, which would result in the audio connection being terminated with the HS.
Either device may terminate an audio connection. In both cases, user intervention is required. On the HS, the user may initiate termination by pressing a button, which would result in the SCO and possibly the ACL connection being terminated. Conversely, the AG may terminate the connection with the HS by operating a function available from the AG.
Assuming an ongoing audio connection between the AG and HS, the volume gain of the microphone and speaker of the HS can be controlled using the AT+VGM and AT+VGS, respectively. The specific volume setting is supplied as a parameter to the respective AT command and has the range of 0 to 15; Figure 7-9 provides further clarification of this sequence of events.
The AG and HS may store these settings after connection release for subsequent use during another connection.
Figure 7-10 illustrates a mechanism that is used to increase or decrease volume when operating a dial-type button that is swung in both directions to increase or decrease the volume.
We have already considered both existing and future usage models in relation to user expectations. Now we will take a closer look at the dependencies that make up this particular profile. Figure 7-11, illustrates these conceptually; the shaded areas are those relevant to this profile. As you can see, the Headset Profile is dependent upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3 and the Serial Port Profile, Chapter 6. Let us now consider, the basic requirements of these dependent components alongside any potential variation from the basic functionality originally offered to us.
Figure 7-11. The dependent components of the Bluetooth protocol stack that make up the Headset Profile. The areas that are shaded are relevant to this profile.
The Headset Profile is reliant upon the abilities afforded to it by the Generic Access Profile, Chapter 2. You may remember from this earlier chapter that a level of basic functionality is attained through the establishment of a set of rules and procedures. Accordingly, the behaviour of such devices is governed by a series of simple rules related to connectivity, discoverability and other common characteristics at the user interface level. These rules help to establish commonality between products, which ultimately results in a predictably beneficial user experience.
This section reflects upon the behavioural aspects of Bluetooth-enabled devices as outlined by the Generic Access Profile, Chapter 2. These mandate a number of rules and procedures that ultimately govern the overall connectability, discoverability and security aspects of Bluetooth-enabled devices.
Table 7-2. The core set of procedures as required by most profiles.
|
PROCEDURES |
DESCRIPTION |
|---|---|
|
Discoverability Mode |
This mode prescribes the overall discoverability of a device, allowing it to be placed into a non-discoverable, limited, or general discoverable mode. The mode would allow devices to become generally available to other users or it can be restricted to personal use. |
|
Connectability Mode |
When determining a baseband connectable state, this mode is used to place a device into a connectable or non-connectable mode. |
|
Pairing |
Pairable and non-pairable modes are used to realise the security aspects when operating or intending to use a device. A device may require authentication and, as such, the user would be required to enter a Bluetooth Passkey. The pairing procedure starts the link key generation process which, in turn, allows authentication to take place. |
Table 7-2, identifies the basic set of procedures and expectations that determine its operation. These procedures allow us to understand the context in which a device operates; for example, a device may wish to be discoverable for a certain period of time or may require a varying level of security, depending upon the services it is capable of offering.
Table 7-3 identifies the set of operations that are specific to this profile. Features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable) to illustrate the expectations of the Generic Access Profile. The Headset Profile requires mandatory support for pairable modes if bonding is supported; bonding is initially offered as optional (see Table 7-5).
Table 7-4 identifies the security requirements for this profile. You may remember from the Generic Access Profile, Chapter 2, that Security Mode 1 is a non-secure mode, where Bluetooth-enabled devices will never initiate any security procedures; whereas, Security Modes 2 and 3 initiate different levels of security procedures at various stages of connection establishment. In this instance, if authentication is provided, then support should be made available for at least Security Modes 2 or 3.
In our final consideration of the basic rules and procedures that are required for the Generic Access Profile, the idle mode procedures outline behavioural characteristics when DeviceA chooses to initiate them against DeviceB. The procedures that are listed in Table 7-5 provide a clear indication of how a device should operate when performing such an activity; let us take our bonding procedure as an example. The term bonding is very much associated with the pairing process; however, bonding occurs when the user has the intent to initiate a trusted relationship with DeviceB.
Table 7-3. The illustration shows specific modes of operation that this profile depends upon to realise its compliant implementation.
|
MODES |
HS |
AG |
|---|---|---|
|
Non-discoverable |
M |
N/A |
|
Limited Discoverable |
O |
N/A |
|
General Discoverable |
M |
N/A |
|
Non-connectable |
N/A |
N/A |
|
Connectable |
M |
M |
|
Non-pairable |
O |
O |
|
Pairable |
O |
O |
Table 7-4. The illustration shows specific security procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
HS |
AG |
|---|---|---|
|
Authentication |
C |
C |
|
Security Mode 1 |
O |
O |
|
Security Mode 2 |
C |
C |
|
Security Mode 3 |
C |
C |
Table 7-5. The illustration shows specific behavioural procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
HS |
AG |
|---|---|---|
|
General Inquiry |
N/A |
M |
|
Limited Inquiry |
N/A |
O |
|
Name Discovery |
N/A |
O |
|
Device Discovery |
N/A |
O |
|
Bonding |
O |
O |
With this intent, the user is prompted to enter a Bluetooth Passkey which in turn instigates the pairing process, that is, the generation of the link keys, where subsequent authentication can then occur. In summary, we realise that there is a specific set of events associated with a procedure and in the Generic Access Profile, Chapter 2, we provide an exhaustive presentation and examine how each procedure is conducted.
The mechanism for providing device discoverability is the provision of a well-structured FHS packet, which is shown in Figure 7-12. This packet is used to identify the remote device, where information such as Bluetooth Device Address (BD_ADDR) and clock offsets is determined. You may also notice from this packet that the Class of Device (CoD) field is also provided. This information is relayed to the user interface which, in turn, provides common characteristics about discovered devices. The CoD is used during the discovery mechanism to learn more about the type of device and what it may be capable of providing. The structure of information is depicted in Figure 7-13 and is made up of 3-bytes (or 24-bits as shown). The following sections now consider the Headset attributes, which will ultimately make use of the Service, Major and Minor Device Class fields.
Figure 7-12. The structure of the FHS packet used only for reference to illustrate the position of the CoD structure.
Figure 7-13. The structure of the class of device, illustrating the Minor Device, Major Device and Service Class fields and their respective lengths.
Table 7-6. The Service Class categorisation for the Headset Profile.
|
SERVICE CLASS | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
23 |
22 |
21 |
20 |
19 |
18 |
17 |
16 |
15 |
14 |
13 |
Bit # of CoD |
|
0 |
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Audio |
This high-level form of defining a Bluetooth device identifies where in the Service Class field the Headset Profile resides; see Table 7-6 which, in turn, determines the category of service; here, the category of service falls within Audio.
This high-level form of defining a Bluetooth device identifies where in the Major Device Class the Headset Profile resides; see Table 7-7 which, in turn, determines the major class grouping. Here, the category falls within Audio, since a headset may be used.
The Minor Device Class in this profile is used to provide further context for the setting within the major class grouping, see Table 7-8. Here, the bit may be set appropriately for Headset to denote the type of service available to the user.
In the Service Discovery Application Profile, Chapter 3, we introduced the characteristics of the mechanisms used to retrieve service information from a remote device. Typically, a client will initiate inquiry and discovery procedures as outlined in our previous section, to learn of the devices in radio range. A client would then make use of an application, which would embody the functionality of the underlying Service Discovery Protocol (SDP). The Service Discovery Application (SrvDscApp) uses an SDP Client to instigate a request to the remote device, where the SDP Server will respond; as such, the AG and HS must employ the use of an SDP client and server respectively, as illustrated in Table 7-9.
Protocol Data Units (PDUs) are used to instruct the SDP server to undertake browsing procedures and to retrieve service record information; you may recall that these PDUs carry payloads about requests containing AttributeIDs and AttributeValues describing what exactly is being sought. As we previously discussed, the client and server operate a request and response paradigm. SDAP will construct PDUs containing information relating to the AttributeID and AttributeValues, in turn instructing the server to carry out its operation. The various request and response PDUs that are required are shown in Table 7-10, where features indicated are marked accordingly.
Table 7-7. The Major Device Class for the Headset Profile.
|
MAJOR DEVICE CLASS | |||||
|---|---|---|---|---|---|
|
12 |
11 |
10 |
9 |
8 |
Bit # of CoD |
|
0 |
0 |
1 |
0 |
0 |
Audio |
Table 7-8. The Minor Device Class for the Headset Profile.
|
MINOR DEVICE CLASS | ||||||
|---|---|---|---|---|---|---|
|
7 |
6 |
5 |
4 |
3 |
2 |
Bit # of CoD |
|
0 |
0 |
0 |
0 |
0 |
1 |
Headset |
A service record is maintained for each service a device is capable of supporting and, as such, a Service Record Handle is created to uniquely identify this. The ServiceRecordHandle is a 32-bit unsigned integer and is stored on the SDP server. The service record shown in Table 7-11 identifies an HS device and Table 7-12 identifies the AG. Both tables provide a list of AttributeIDs, which in combination would identify the services available for the Headset Profile. A minimum of two attributes are required to make a service record; these are ServiceRecordHandle and ServiceClassIDList, where it must contain at least one UUID.
When browsing for services on the remote device, a local device constructs a search pattern using a Universally Unique Identifier (UUID). A UUID is a 128-bit value, which has been shortened for use within Bluetooth applications. The shortcut has been provided by first establishing a Bluetooth Base UUID, which we discussed in the Service Discovery Application Profile, Chapter 3.
The UUIDs that have been presented so far are aliases and take the form of what is referred to as a 16-bit UUID or a 32-bit UUID but, in turn, they should all refer to the 128-bit notation. These UUIDs have been assigned and can be referenced in the Bluetooth Special Interest Group, Bluetooth Assigned Numbers, v1.1, February 2001. For the search pattern to be successful, they all need to be converted to the 128-bit notation, since they will all be compared at this range. An arithmetic conversion algorithm is used to construct the 128-bit value.
Table 7-13 summarises the service class UUIDs used to identify the particular profile in use; this also correlates with the identification of the device during a device discovery procedure as previously outlined in Section 7.5.1.1, Generic Access.
Table 7-9. As a minimum, the local device must support the use of a client application and the remote device must support the use of a server.
|
FEATURE |
AG |
HS |
|---|---|---|
|
SDP Client |
M |
X |
|
SDP Server |
X |
M |
Table 7-10. The list of PDUs that are required for the operation of the Headset Profile.
|
PDU |
AG |
HS |
|---|---|---|
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
M |
X |
|
|
X |
M |
|
|
O |
X |
|
|
X |
O |
As part of the service record, the dependent underlying protocols are also identified. The local device retrieves this information, where it can fully understand the exact requirements needed to fulfil the service. The Headset Profile is dependent on the protocols, as shown in Table 7-14, which also shows their associated UUID values.
In the Serial Port Profile, Chapter 6, we introduced the conceptual and functional nature of RFCOMM and how it provides an emulated serial port presence. Several distinctions were made between the various types of applications. The purpose of making these distinctions was to enable clarification and understanding of RFCOMM’s composition. In this particular application context, the creation of an emulated serial port would be transparent to the user. The Headset Profile is dependent upon the operation of the Serial Port Profile, and, as such, is required to establish an emulated serial port as part of its communication link with the remote device.
The term cable replacement application was introduced in our earlier chapter and distinguishes between the different scenarios available. It refers to specific Bluetooth applications that create implicit emulated serial ports, which remain transparent to the user to complete the creation of a communications link.
Specific detail has been provided to illustrate how data is communicated over an emulated serial port connection, whereby a Data Link Connection (DLC) is established between two peer devices, namely AG and HS. We have also looked at the fields that make up our service record for this profile. The ProtocolDescriptorList field is used to describe the set of protocols that the profile intends to use and, as such, the RFCOMM protocol identifier contains a parameter, which contains the Server Channel number.
The Server Channel is used in combination with a Data Link Connection Identifier (DLCI), which is then used to uniquely identify the active DLC. This connection is then mapped onto a connectionless orientated L2CAP Channel Identifier (CID).
Table 7-11. The list of mandatory and configurable items that make up the service record for the HS device.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 ServiceClass1 |
With an |
ProtocolDescriptorList
Protocol0
Protocol1
ParameterFor1 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
|
|
With an |
Table 7-12. The list of mandatory and configurable items that make up the service record for the AG device.
|
ATTRIBUTE |
DESCRIPTION |
|---|---|
|
|
With an |
ServiceClassIDList ServiceClass0 ServiceClass1 |
With an |
ProtocolDescriptorList
Protocol0
Protocol1
ParameterFor1 |
With an |
BluetoothProfile
DescriptorList
Profile0
ParameterFor0 |
With an |
|
|
With a base |
Table 7-13. The list of service classes that match a corresponding profile. This correlates with our previous Generic Access section.
|
CLASSES |
UUID |
|---|---|
|
|
|
|
|
|
|
|
|
Table 7-14. The list of protocols that are used in this profile; their associated UUID values are also shown.
|
PROTOCOL |
UUID |
|---|---|
|
|
|
|
|
|
In this section we highlight the specific features that are required to realise a compliant Headset Profile and illustrate the features or capabilities that are expected from the Serial Port Profile.
The use of the RLS command is encouraged to keep peer devices informed of any state change. In one such instance, an emulated serial port may interface to a Type II application (physical serial port), where overruns or parity errors may occur. An application that makes use of RS232 port configuration parameters should expose these settings through an appropriate Application Programming Interface (API) function; this is of particular relevance when interfacing to Type II applications.
In Section 7.3, Profile Principles, we introduced an illustration that identifies the audio port emulation and driver components created with the help of RFCOMM. It is above this that an audio application would reside, using the serial port emulation provided by RFCOMM. The HS and AG would be capable of supporting the commands and responses as defined in Table 7-18 and Table 7-19, respectively; these are based upon the International Telecommunications Union (ITU-T) Telecommunications Sector v.250. [2]
Table 7-15. The set of capabilities that are required from the initiating party, denoted here by the AG device.
|
PROCEDURE |
AG |
HS |
|---|---|---|
|
Initialise an RFCOMM Session |
M |
X |
|
Terminate an RFCOMM Session |
M |
M |
|
Establish a new DLC Connection |
M |
X |
|
Disconnect a DLC Connection |
M |
M |
|
Emulate RS232 Control Signals |
C |
C |
|
Transfer Data |
M |
M |
|
Test Command |
X |
X |
|
Flow Control |
C |
C |
|
RLS |
O |
O |
|
PN |
O |
O |
|
RPN |
O |
O |
Table 7-16. The set of capabilities that are required from the responder party, denoted here by the HS device.
|
PROCEDURE |
AG |
HS |
|---|---|---|
|
Initialise an RFCOMM Session |
X |
M |
|
Terminate an RFCOMM Session |
M |
M |
|
Establish a new DLC Connection |
X |
M |
|
Disconnect a DLC Connection |
M |
M |
|
Emulate RS232 Control Signals |
M |
M |
|
Transfer Data |
N/A |
N/A |
|
Test Command |
M |
M |
|
Flow Control |
M |
M |
|
RLS |
M |
M |
|
PN |
M |
M |
|
RPN |
M |
M |
The general format used for the HS to send an AT command to the AG is provided in Table 7-17; the AG, however, will not echo the command and, as such, this is a deviation from the ITU-T Recommendations v.25ter specification.
Table 7-17. The default command is used, where no echo from the AG is required. The result code is used to confirm a successful operation, with an OK, where an unsuccessful operation is denoted with an ERROR.
|
COMMAND |
RESULT |
|---|---|
|
|
|
Table 7-18. The RING command is used to notify the HS of an incoming call.
|
COMMAND |
DESCRIPTION |
|---|---|
|
|
This is the incoming call notification to the HS, as indicated in the ITU-T Recommendation. |
Table 7-19 provides clarification with regard to the optional AT command capability that may be supported by both the AG and HS. These capabilities extend to the control of the speak and volume gain, which in turn allow the user of the headset to increase or decrease the volume settings of the equipment.
The L2CAP layer provides transparency for the upper layers of the stack from the layers typically found within the host controller. L2CAP payloads are passed to the Host Controller Interface [3] (HCI), which is then subsequently passed onto the Link Manager Protocol (LMP). The range of upper layers, which include RFCOMM, SDP and the TCS, all make use of the capabilities offered to us by L2CAP. Its primary role is to provide protocol multiplexing, allowing numerous simultaneous connections to be made, and it also provides the ability for segmentation and reassembly. This refers to the ability to manage large payloads in the application, which may need to be fragmented into smaller payloads for the lower-layers to manage; these are then transmitted over the air-interface. Finally, the L2CAP layer exchanges Quality of Service (QoS) information, ensuring that sufficient resources are available and that both Bluetooth devices are attaining the best service.
In Table 7-20, we summarise the broad capabilities that are expected from L2CAP. In the table, you will notice features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); these will determine what is expected from the features at the L2CAP layer.
Table 7-19. The command set that is optional for the AG and HS to increase and decrease gain levels with the speaker and microphone of the units. A setting of 0 to 15 is used and recommended.
|
COMMAND |
DESCRIPTION |
|---|---|
|
|
The AG issues this command to set the level of gain in the microphone of the HS. The HS reports the level of gain to the AG using the same command structure and setting. |
|
|
The AG issues this command to set the level of gain in the speaker of the HS. The HS reports the level of gain to the AG using the same command structure and setting. |
Table 7-20. The illustration shows specific procedures that this profile depends upon to realise its compliant implementation.
|
PROCEDURE |
AG |
HS |
|---|---|---|
|
Connection-orientated Channel |
M |
M |
|
Connectionless Channel |
X |
X |
|
Connection Establishment |
M |
M |
|
Configuration |
M |
M |
|
Connection Termination |
M |
M |
|
Echo |
M |
M |
|
Command Rejection |
M |
M |
|
Maximum Transmission Unit |
M |
M |
|
Flush Timeout |
M |
M |
|
Quality of Service |
O |
O |
In Table 7-20, we have identified that Connection-orientated Channels are mandatory, whereas Connectionless Channels are excluded; this type of channel is aimed at broadcasting, where all devices may be targeted. L2CAP uses PDUs to transport connection, signalling and configuration options, which will be discussed in a moment. The higher-layers of the Bluetooth protocol stack will instigate a connection with L2CAP using the L2CA_ConnectReq request packet, where the corresponding result is contained within the L2CA_ConnectRsp response packet. An L2CA_ConnectRspNeg negative response packet is used to denote a response, where the connection with the remote device was unsuccessful. Since our profile resides above L2CAP and employs its services, we are only concerned with the upper protocol layer of L2CAP. This higher functionality is offered to us through a series of L2CAP events and is denoted through the prefix L2CA_ (see Table 7-21).
When creating an L2CAP connection between two devices, a Protocol/Service Multiplexor (PSM) value is employed to denote the higher-layer protocol that is using the connection; Table 7-22 identifies these values and the corresponding protocols they represent. The value of 0x0003 (RFCOMM) is used for this profile.
When establishing communication with a remote device, a signalling channel is created and reserved for use during connection, disconnection and configuration of subsequent L2CAP connections. A channel is used to describe the communication and data flow that exists between L2CAP entities and Table 7-23 illustrates the range of CID that are used to identify the channel type. As we can see in Table 7-20, Connection Establishment and Termination is mandatory in the local device, although the remote device may be capable of initiating and terminating a connection to the local device. The L2CA_DisconnectReq request packet is used to terminate the connection with the remote device and an L2CA_DisconnectRsp response packet is used to ascertain the result of the termination; although all disconnection requests must be completed successfully. The support of Configuration is shown as mandatory and we will discuss these specific options in more detail in the following section. Finally, Echo and Command Rejection are both mandatory for a compliant Headset Profile.
Table 7-21. The range of prototypes used to illustrate how L2CAP is architected and how interaction between higher- and lower-layers is achieved. For this discussion, our concern here is with the higher-layer.
|
PROTOTYPE |
DESCRIPTION |
|---|---|
|
|
This prefix prototype is used to denote the higherlayer interaction, typically used by RFCOMM, SDP and TCS. |
|
|
This prefix is used to denote peer-to-peer signalling interaction of L2CAP entities. |
|
|
Finally, this prefix denotes lower-layer interaction, where L2CAP interfaces with the LMP layer. |
In establishing a connection with the remote device, the channel is subject to configuration and the higher-layer prototype L2CA_ ConfigReq request packet is used to carry configuration requests. Its associated response is contained within the L2CA_ConfigRsp packet; an L2CA_ConfigRspNeg packet is used to denote a negative response during configuration where, for example, the suggested Maximum Transmission Unit (MTU) is too large. In Table 7-20, we have identified that the MTU and Flush Timeout parameters are mandatory, whereas the QoS is optional.
Table 7-22. The PSM values that are used to identify the higher-layer protocol.
|
PSM |
DESCRIPTION |
|---|---|
|
|
SDP |
|
|
RFCOMM |
|
|
TCS-BIN |
|
|
TCS-BIN-CORDLESS |
Table 7-23. The CIDs that are used to represent the logical channel.
|
CID |
DESCRIPTION |
|---|---|
|
|
Null |
|
|
Signalling Channel |
|
|
Connectionless Reception Channel |
|
|
Reserved |
|
|
Dynamically Allocated |
The default MTU setting for the signalling channel is 48-bytes, whereas other channels may be capable of transferring larger payloads; essentially, the MTU determines the size of payloads that are capable of being exchanged between two devices. During configuration, the local device will inform the remote device that it is potentially capable of accepting larger payloads. If the remote device is unwilling to accept a larger MTU, then the local device is informed with the response contained within the L2CA_ConfigRspNeg packet.
When L2CA_ request and response packets are being exchanged, the Flush Timeout parameter is used to determine how long the local device is prepared to continue to transmit an L2CAP fragment before it gives up; the packet is subsequently flushed or, in other words, discarded. The suggested Flush Timeout value is sent during the L2CA_ ConfigReq request packet. However, if no value is set, then the default value is used. The Headset Profile uses the default value of 0xFFFF.
As we have already mentioned, the QoS configuration is optional, but if it is used during an L2CA_ConfigReq request then the best effort service is established as a default; the available services that are supported during an L2CAP channel are shown in Table 7-24. However, if the QoS is set at Guaranteed, then parameters such Token Rate, Token Bucket, Peak Bandwidth, Latency and Delay Variation, are used to determine an acceptable guaranteed service, where the L2CA_ConnectRspNeg will indicate that these values are unacceptable. These parameters are then subject to further negotiation.
The Link Manager (LM) layer sits between the HCI and the LC, although on a host-less system the LM will have direct interaction with L2CAP. It accepts commands from HCI and translates them into operations for the LC, where ACL and SCO links are created and established. It is during this stage of ACL and SCO establishment that a master-slave switch would be performed as governed by the requirements of this profile. The LM is also responsible for placing the device into a low-power mode, which includes hold, sniff and park.
Table 7-24. The range of service definitions that are used during QoS.
|
SERVICE |
DESCRIPTION |
|---|---|
|
No Traffic |
This indicates that the channel will not be sending any traffic and, as such, any parameters can be ignored. |
|
Best Effort |
This default value attempts to achieve a minimum service with the remote device, where no guarantees are offered. |
|
Guaranteed |
With this service definition, we indicate that we wish to achieve the maximum bandwidth permitted. This, of course, is subject to the nature of a wireless environment. |
In providing general error management, devices that operate mandatory procedures during interoperability must either acknowledge their support or provide a suitable reason for failure. The LMP_Detach PDU is used to inform the device of the error that occurred; typically, the reason unsupported LMP feature (0x1A) is reported (see Appendix A).
In our following discussion, we take an opportunity to explore the dependencies that make up the Headset Profile, where we provide a narrative of the capabilities that are expected from this layer. These are identified in Table 7-25; in the following subsections, we discuss the specific procedures in more detail.
Table 7-25 summarises the broad capabilities that are expected from the LM and in the table you will notice procedures are marked appropriately; these will determine what is expected from the procedures at the LM. What has been included in the table is a set of profile deviations.
A SCO link is set up using the HCI_Add_SCO_ Connection command (see Table 7-26), where a series of Voice_Setting parameters are used to denote the type of SCO channel and the audio coding schemes. The Voice_Setting parameters are written using the HCI_Write_Voice_Setting command and are shown in Table 7-27.
It is assumed that the partying devices have an existing ACL communications link, where pairing, authentication and encryption (if required) have already taken place. The ACL Connection_Handle parameter is used, in part, to then create our SCO connection using the HCI_Add_SCO_Connection command.
Although the host controller generates a Command_Status event, it does not indicate that the SCO connection has been created. The host controller for both devices uses the Connection_Complete event to notify both hosts whether the SCO connection has been successful or not, where the new Connection_Handle and Link_Type identify the new connection. You may also wish to note that the Packet_Type parameter is used to specify the type of high quality voice transmission, where HV1, HV2 or HV3 can be requested over the SCO link.
Table 7-25. The mandatory requirements that are required for a compliant Headset Profile.
|
PROCEDURES |
SUPPORT |
|---|---|
|
SCO Links |
M |
The Voice_Setting parameters are shown in more detail in Table 7-28; the parameters make use of two bytes, but only the first ten bits are useful. The HCI_Write_ Voice_Setting command also returns a Status of whether the command succeeded or not. The Voice_Setting parameters define the behaviour of all SCO connections that are active between partying devices.
The LC layer is the lowest-layer depicted in the dependencies of this profile. Furthermore, the LC is responsible for a large number of core capabilities. It manages air-to-interface transactions and determines the fundamental timing of ACL and SCO data packet transmission and reception, as well as coordinating effort at its upper-edge with the LM. It also encompasses the management of the various packet types and the various inquiry and paging procedures that are available. The following subsections provide clarity with regard to the capabilities that are required at the LM level for the Headset Profile. In our understanding of the dependencies, we begin by examining in more detail the supported capabilities. If you are a developer providing profile-specific applications, then it is doubtful that you will engage in much of this component, although in some audio-related applications direct access may be required, where a faster transport mechanism can be supported. Nevertheless, many manufacturers have architected an audio-specific API for a intelligible access to this component.
Table 7-26. The command and event that are used in combination to create a SCO connection. The Host Controller first sends the Command_Status event, but when the connection has been established the Connection_Complete event is generated on both devices.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
|
|
|
Table 7-27. The commands and events that are used in combination to write the voice setting parameters for a SCO link.
|
COMMAND |
PARAMETERS |
|---|---|
|
|
|
|
EVENT |
PARAMETERS |
|---|---|
|
|
|
Table 7-28. The Voice_Setting parameters that are used to define the behaviour of all active SCO connections.
|
PARAMETERS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
9 |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
Bit # of Voice Setting Parameters |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
Linear |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
µ-Law Baseband Coding |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
A-Law Baseband Coding |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1’s Complement |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
2’s Complement |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
Sign-magnitude |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
8-bit Input for Linear PCM |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
0 |
0 |
16-bit Input for Linear PCM |
|
0 |
0 |
x |
x |
x |
0 |
0 |
0 |
0 |
0 |
Used for denoting the PCM Bit Offset |
|
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
CVSD air-coding format |
|
0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
µ-Law air-coding format |
|
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
A-Law air coding format |
Table 7-29 summarises the broad capabilities that are expected from the LC and in the table you will notice features are marked with M (Mandatory), O (Optional), X (Excluded), C (Conditional) and N/A (Not Applicable); these dictate the feature expectations at the LC.
An inquiry procedure is used to learn of the other devices in radio range, where the BD_ADDR and clock offsets are obtained; it is DeviceA that will enter an inquiry substate to perform this procedure. A device that wishes to be discovered (DeviceB) will enter an inquiry scan substate, where the device will respond with an inquiry response. In this state, DeviceB is waiting to receive an Inquiry Access Code (IAC). From an application perspective, these modes of operation are discussed in more detail in the Generic Access Profile, Chapter 2. It is here that specific rules are determined with regard to the behaviour of such devices and how long these devices can operate in such modes. When devices have been discovered, this information is passed over to the Service Discovery Application Profile, Chapter 3, which manages the specific attributes that make up that device. What is being established here, as a dependency, is that the Bluetooth protocol stack must encompass and support such behavioural procedures for this profile to be considered compliant.
The inquiry substate and inquiry scan substate procedures are the initial methods used to learn of other devices in radio range; to this extent, the device has discovered sufficient information to gain a connection with the remote device. This is achieved when DeviceA has the intent to create a connection with DeviceB; DeviceA is now placed into a paging substate, where it will periodically transmit the Device Access Code (DAC). The DAC is used to target the device directly and the clock offset is used to gain an idea of the clock cycle of DeviceB. These parameters were originally obtained during our inquiry procedures. If DeviceB wishes to be connected, then it will enter a page scan substate and will respond accordingly to DeviceA. An inquiry procedure may be avoided if the BD_ADDR is already known, although a connection may take a little longer if the clock offset is not known.
There are numerous packet types available and Table 7-30 identifies those most often used for profile support. There are also a number of common packet types that are used for general purpose transport; for example, the ID packet is used for inquiry procedures and a POLL packet would be sent by DeviceA to determine if a slave is active on a channel.
The DM1 packet type is used to transmit control data over any connection, but it may be used to transport a genuine payload. HV1, HV2, and HV3 are various SCO packet types to carry audio-specific data, where a DV packet can combine ACL and SCO specific data; their support in this profile is reflected in Table 7-30. Various ACL packet types are also available; in fact, seven types including the DM1 type are attributed to carrying user-specific data. These include DH1, DM3, DH3, DM5, DH5, and AUX1; similarly, Table 7-30 summarises their support in this profile.
Table 7-31 summarises voice codec support in this profile. Voice coding schemes are used to provide compression and to overcome potential errors in the data transmission. CVSD provides the second scheme, which is particularly efficient for voice communication; it also tolerates potential errors in the audio data. The PCM has two types of logarithmic compression; these are A-law and µ-law, where either compression technique can be applied on the voice channels over the air-interface.
The Headset Profile purports to define the ideal of the Ultimate Headset.
A headset may comprise a small unit with limited functionality allowing the user to establish and accept incoming calls.
Other headset models may incorporate the Voice Recognition function to enable further outgoing call capabilities.
There is some overlap of functionality with the Car Hands-Free Profile.
Some functionality is still provided on the AG.
The Headset Profile must support SCO links, with the provision of audio CODEC support.
There are two types of audio CODEC support provided within Bluetooth applications: PCM (A-law and µ-law) and CVSD.
The AG device discovers the headset and may be prompted to supply a Bluetooth Passkey.
The Headset Profile is built upon the Generic Access and Serial Port Profiles.
AT commands are used to provide control.
[1] In the early stages of product introduction to the marketplace, it is quite common to see an initial mark-up on the product itself. Indeed, as such products increase in popularity, the price more often is reflected in the numbers sold.
[2] The new International Telecommunications Union (ITU-T) Telecommunications Recommendation, Series V: Data Communication over the Telephone Network v.25ter, supersedes the original v.250 document.
[3] L2CAP payloads are passed directly onto LMP when implemented on a hostless system.