The Bluetooth Device Address parameter uniquely identifies the Bluetooth device and is often referred to as BD_ADDR at the baseband level. For every Bluetooth device, there will be a unique address assigned to it. It is based upon the Media Access Control (MAC) address notation, which is already used to uniquely identify a computer that is connected to a Local Area Network (LAN). The BD_ADDR is retrieved during an inquiry or device discovery procedure and is described as the Bluetooth Device Address at the user interface level as previously shown in Figure 2-3 and Figure 2-4.

We show in Table 2-2, the HCI_Read_BD_ADDR command, which is used to request the device address from the local device and the Command_Complete event is used to acknowledge completion of the request. In the return parameters, the success of the command is determined by the Status parameter and the BD_ADDR parameter will contain the address of the local device.

At the baseband level, BD_ADDR is represented as 48-bits; however, the user will see a 12 byte hexadecimal notation, where this representation may be subsectioned for an easy read. The presentation of this number will have the most-significant byte (MSB) and least-significant byte (LSB) shown from left-to-right.

When performing a device discovery procedure, a user-friendly name is also retrieved and presented to the user, as we have seen in Figure 2-3 and Figure 2-4. The unique Bluetooth address is not a sufficient description to determine what the device is capable of and, as such, a user-friendly name can be provided to aid identification. On the user interface level, this parameter is referred to as the Bluetooth Device Name.

We show in Table 2-3, the HCI_Remote_Name_Request command, which is used to request the user-friendly name from the remote device and the Remote_Name_ Complete event is used to acknowledge completion of the request.

The following Link Manager Protocol (LMP) Protocol Data Units (PDUs), in Table 2-4, detail the LMP commands that are used to retrieve the user-friendly description. The Bluetooth Device Name can be up to 248-bytes in length, although not all bytes have to be used. There may be restrictions in what can be displayed at the user interface level and generally only the first 20 bytes can be shown. What can be displayed will typically be determined by the restriction of the user interface of the device itself and thus may be implementation-specific. Such environments may include an embedded cordless handset or a mobile phone, which has a limited display.

The LMP_name_req command is sent indicating which fragment to expect. The response is then received with the LMP_name_res command, where the parameters determine the length of the name and the fragment, since the Bluetooth Device Name can be fragmented over several DM1 ^[4] packets.

Before two devices can have a relationship, there has to be an element of trust. The Bluetooth Passkey is used to build that trusted relationship prior to performing authentication. In Figure 2-5, the user is prompted to enter a Bluetooth Passkey to commence the process of establishing the trusted relationship.

Figure 2-5. The screen shot shows a user being prompted to enter a Bluetooth Passkey before two devices can have a trusted relationship. (Courtesy of TDK Systems Europe.)

We show in Table 2-5, the HCI_PIN_Code_Request_Reply command, which is used to respond to a PIN_Code_Request event, where it specifies the passkey to use for the current connection. This is typically generated during an HCI_Create_Connection or through the HCI_Authentication_Requested commands.

The Bluetooth Passkey is often referred to as the Personal Identification Number (PIN) and is described as PIN_UI for user interface representation and PIN_BB for baseband level representation. However, the user will only see the term Bluetooth Passkey when connecting to DeviceB, as previously shown in Figure 2-5.

The passkey or PIN is then used in the pairing procedure and is further used to generate a common link key; there will be more about this later (see Section 2.5.4, Pairing). In Figure 2-6, we illustrate the user being prompted when an invalid passkey has been entered; in some instances, the user may be prompted again to enter a valid passkey.

Figure 2-6. The screen shot shows a user being prompted when the incorrect Bluetooth Passkey was entered. (Courtesy of TDK Systems Europe.)

Consideration should also be given to devices that do not have a user interface but must still utilise a Bluetooth Passkey. In these instances, it is possible that this passkey can be stored within the device itself and should only take the form of decimal digits. Remember, the inquiring device (DeviceA) should also be capable of supporting the entry of decimal digits. A Bluetooth headset may require the user to authenticate with the device and, as such, enter a valid passkey. In such instances, manufacturers have either supplied the user with a Bluetooth Passkey card or have made it part of the unique serial number.

Whether the passkey is stored or entered in by the user a transformation has to occur from PIN_UI to PIN_BB to allow the generation of the link key for the pairing procedure, as we previously touched upon. This is achieved through mapping alphanumeric characters, which are entered on the user interface level to the UTF-8 ^[5] format for the appropriate baseband representation. The user interface level is also capable of managing a range of alphanumeric characters, which include decimal and alphabetic. The PIN_BB is 128-bits in length or 16-bytes, although not all bytes have to be used and, as such, the PIN_UI may be less than the maximum 16-bytes available.

When performing a device discovery, a Bluetooth Device Class is retrieved to specifically identify the type of device and the type of services that it is capable of supporting. Within an FHS ^[6] packet, a Class of Device (CoD) field is used to provide sufficient information with regard to the service, major and minor class groupings; Figure 2-7 shows the placement of the CoD field within the FHS packet.

Figure 2-7. The structure of the FHS packet used only for reference to illustrate the position of the CoD structure.

The CoD field is further sectioned into 3-bytes (or 24-bits) as shown in Figure 2-8. In the illustration, we can uniquely identify the Service, Major and Minor device class grouping, where in the following sections we will look more closely at the parameters which make up this field.

Figure 2-8. The structure of the class of device, illustrating the Minor Device, Major Device and Service Class fields and their respective lengths.

The Service class is the highest form of categorising a Bluetooth device. In Table 2-6, we show the service class definitions that are currently available.

Table 2-7 identifies the Major class grouping. This represents another level of granularity for the definition of a Bluetooth device.

Taking the granularity to the next level, the following tables identify further groupings when the Major Device class is not suitable, although the correct interpretation is given for the Major Device class context. In Table 2-8, we illustrate the available groupings for the Computer Major Class.

In Table 2-9, we illustrate the available groupings for the Phone Major Class. In Table 2-10, we illustrate the available groupings for the Access Point Major Class. Table 2-10 shows the loading on the access point, which occupies bits 5, 6 and 7 of the minor device field; the lower 3-bits of the field are reserved.

In Table 2-11, we illustrate the available groupings for the Audio/Video Major Class. In Table 2-12, we illustrate the available groupings for the Peripheral Major Class. The field is sectioned, where the upper two bits, 7 and 6 are used to specify the Keyboard, Mouse and a Combo device. The lower four bits can then be used in combination for multifunctional devices; this is shown in Table 2-13.

In our final look at the class grouping, Table 2-14 illustrates the available groupings for the Imaging Major Class. The field is also sectioned, where the upper four bits, 7, 6, 5 and 4 are used to specify the Display, Camera, Scanner and a Printer device.

The lower two bits can then be used in combination for multifunctional devices; this is shown in Table 2-15.

The following commands, as shown in Table 2-16 and Table 2-17, are used in combination to identify and set the device categorisation as we previously discussed. The HCI_Read_Class_of_Device parameter is used to retrieve the capabilities of the local device, which in turn informs other devices of its capabilities. A Command_Complete event is used to acknowledge a successful operation.

The HCI_Write_Class_of_Device parameter is used to set the capabilities for the local device, which in turn informs other devices of its capabilities. A Command_Complete event is used to acknowledge a successful operation.

This mode inhibits a device from being discovered and at the user interface level is described as non-discoverable or in a non-discoverable mode. As such, the device will never enter the inquiry response state. Its use within this profile is optional, although it becomes mandatory if the limited discovery mode is supported.

This mode provides limited discoverability and, at the user interface level, is described as discoverable or in a discoverable mode. Again, its use within this profile is optional, but the governing profile may dictate otherwise.

When a device is placed in the limited discoverable mode, it sets bit 13 in the service class field as shown in Table 2-24. The table provides a comparative perspective with regards to its placement with other settings, which we discussed in an earlier section.

Limited discoverability provides flexibility with regard to making specific events temporarily available, where the mode should not be available for more than T_GAP⁽¹⁰⁴⁾. The procedure for the LIAC is provided by two scanning methods: parallel or sequential, but only one is used.

In the parallel scanning method, the device will enter the inquiry scan state once in T_GAP⁽¹⁰²⁾ and perform the inquiry scan for the GIAC or LIAC at least T_GAP⁽¹⁰¹⁾. Similarly, the sequential scanning method for the device will enter the inquiry scan state once in T_GAP⁽¹⁰²⁾. However, it will scan for the GIAC for at least T_GAP⁽¹⁰¹⁾, and enter the inquiry scan state more frequently than once in T_GAP⁽¹⁰²⁾, but scan for the LIAC for at least T_GAP⁽¹⁰¹⁾. Precedence is provided for the inquiry response state when an inquiry message is received so that the message can be appropriately actioned.

The following sections now further clarify the limited inquiry and device discovery procedures for DeviceA, whereas the behaviour of DeviceB has been presented in previous sections. Here, we want to look specifically at the behaviour of DeviceA when the device is in an idle state.

Limited Inquiry

The limited inquiry procedure obtains the BD_ADDR, clock, ^[9] CoD and the current status of the page scan mode. At the user interface level, the term Bluetooth Device Inquiry is used to describe the process, as previously shown in Figure 2-9. As a minimum, one inquiry procedure is mandatory where bonding is made available; otherwise the availability of the limited inquiry method is optional.

Table 2-24. A small section of the major service classes that are set in the Service Classes section of the class of device field.

											SERVICE CLASS
23	22	21	20	19	18	17	16	15	14	13	Bit # of CoD
0	0	0	0	0	0	0	0	0	0	1	Limited Discoverable Mode
											…
0	1	0	0	0	0	0	0	0	0	0	Networking
0	0	0	0	0	0	1	0	0	0	0	Telephony

Figure 2-11 describes a sequence of events that occur when DeviceA wishes to learn of other devices in radio range. DeviceA uses the LIAC to perform the inquiry and will remain in the inquiry state for at least T_GAP⁽¹⁰⁰⁾, see Table 2-18. In the illustration provided, DeviceB² responds, whereas the other two devices have been configured for non-discoverability and general discoverability. Devices that have been configured for limited discoverability will only respond to the LIAC and, as such, are only available for a limited period of time or for specific events. Inquiring devices have the option to use GIAC or LIAC, since many circumstances may limit the response of the acceptor. Timing restrictions are applied to this operation, where the inquiry has to be completed within the time available to the acceptor during the limited discoverability (T_GAP⁽¹⁰³⁾).

Figure 2-11. The sequence of events that occur when DeviceA wishes to learn more about the devices in radio range. In the illustration provided DeviceB¹ is configured for non-discoverable mode and DeviceB³ is configured for general discoverability and, as such, neither produces an inquiry response.

Limited Device Discovery

The limited device discovery procedure obtains the same set of parameters initially retrieved by the limited inquiry. However, the limited device discovery procedure also requests the Bluetooth Device Name, although it can be obtained at a later stage during connection establishment. At the user interface level, the term Bluetooth Device Discovery is used to describe the process and in Figure 2-12, we can see the user has specifically selected the type of devices he or she wishes to see.

Figure 2-12. Here we can see a user configuring his or her Bluetooth device to discovery specific devices. (Courtesy of TDK Systems Europe.)

The HCI_Set_Event_Filter command is used to specifically filter out other devices during an inquiry. The command can be configured to allow only new devices to respond to a device with a certain CoD and a device with a specific BD_ADDR should only respond.

In Table 2-25 we illustrate the HCI_Set_Event_Filtercommand that is used by the host to select different event filters. As a default, the Auto_Accept_Flag is off and, as such, no filters have been defined; this flag is formed as part of the Filter_Condition_Type parameter. As part of the Filter_Condition_Type, Inquiry_Result event filter parameters, a device may be configured for all new devices to respond to an inquiry process or a device should respond with a specific CoD or BD_ADDR. A Command_Complete event is generated informing the host that the filter has been created, where an Inquiry_Result event is then generated informing the host of the results. However, the Filter_Condition_Type, Connection_Setup filter parameters enable connections from all devices or allows connections from a specific device with a CoD or a BD_ADDR. In this instance, a Connection_Request event is generated if any of these conditions are met.

In Table 2-25, we also see the parameters that make up our Inquiry_Result event filter and the Connection_Request event, which are generated as a result of defining the Filter_Condition_Type parameter. The host controller informs the host as soon as the inquiry response is received from the remote device.

Like the limited discoverable mode, the user interface describes this option as discoverable or in a discoverable mode. This mode is generally open and available with no specific conditions attached. Its use within this profile is optional, but again the governing profile may dictate otherwise.

The device responds to the general inquiry using the GIAC, but never responds to a LIAC when configured for general discoverable mode. Whilst in this mode, a device will enter the inquiry scan state more frequently than once in T_GAP⁽¹⁰²⁾ and will scan for the GIAC for at least T_GAP⁽¹⁰¹⁾.

The following sections now further clarify the general inquiry and device discovery procedures for DeviceA. The behaviour of DeviceB has been presented in previous sections. Here, we want to look specifically at the behaviour of DeviceA when the device is in an idle state, that is, awaiting interaction in this particular mode of operation.

General Inquiry

The general inquiry procedure obtains the BD_ ADDR, clock, CoD and the page scan mode of the discovered devices. Devices that have been configured for limited discovery will also respond when issued a GIAC. At the user interface level, the term Bluetooth Device Inquiry is used to describe the process in hand, see Figure 2-9. As a minimum, one inquiry procedure is mandatory, where bonding is made available—otherwise the availability of the general inquiry method is optional.

Figure 2-13 provides a sequence of events that occur when DeviceA wishes to learn of other devices in radio range. DeviceA uses the GIAC to perform the inquiry, where it will remain in the inquiry state for at least T_GAP⁽¹⁰⁰⁾, see Table 2-18.

Figure 2-13. The sequence of events that occur when DeviceA wishes to learn more about the devices in radio range. In the illustration provided, DeviceB¹ is configured for non-discoverable mode and, as such, does not produce an inquiry response.

When a device is configured for non-connectable mode, it will never enter the page scan state and, at the user interface level, it is described as non-connectable or in a non-connectable mode; its use within this profile is optional.

A device configured for connectable mode will enter the page scan state awaiting its own DAC and its use within this profile is mandatory. At the user interface level, it is described as connectable or in a connectable mode.

At the user interface level, the user is presented with the configuration for the device as bondable mode or simply bondable. Its use within this profile is optional, although becomes mandatory if the bonding procedure is supported. When in a pairable state, DeviceB should respond when it receives an LMP_in_rand, with LMP_accepted or with LMP_in_rand if the device has a fixed passkey.

At the user interface level, the user is presented with the configuration for the device as non-bondable mode or simply non-bondable. Its use within this profile is optional, but the governing profile may dictate otherwise. When in the non-pairable state, DeviceB should respond when it receives an LMP_in_rand, with LMP_not_accepted, where the reason parameter should indicate pairing not allowed (0x18), see Appendix A.

The term Bluetooth Authentication is used at the user interface level and is performed when the devices share a common link key or initialisation key. ^[10] You may remember in our earlier discussion that pairing occurs prior to the authentication process, which is the process of obtaining the passkey and generating the initialisation key. This process is, of course, subject to the configuration of the pairable mode, where the device can be configured not to engage in pairing.

The authentication process encompasses LMP Authentication, but LMP Pairing must have been performed prior to this event. As for the LMP Authentication procedure, this is primarily based on a challenge-response scheme. Here, the verifier or DeviceA sends the LMP_au_rand command, containing a random number to the claimant or DeviceB; the random number forms the challenge aspect of this scheme. The response, forming the final part of this scheme, is sent to the verifier using the LMP_sres command, which contains the result of the operation. If the operation is what the verifier expected then it considers the claimant as authenticated.

The LMP Pairing procedure occurs when there is no link key and, as such, if an LMP_au_rand is sent to the claimant it will respond with LMP_not_accepted offering the reason as key missing (0x06), see Appendix A. If a key has been previously associated with the claimant, then the claimant proceeds to calculate the response and provides the verifier with a response through LMP_sres. However, if the calculated response is incorrect the verifier can terminate the connection with the command LMP_detach, offering the reason as authentication failure (0x05), see Appendix A; Table 2-27, summarises the LMP commands used during authentication and Figure 2-18 provides a sequence of events that occur during the LMP Authentication procedure.

Figure 2-18. The sequence of events for LMP Authentication, which follow the LMP Pairing sequence.

This section is provided to supplement the notion of encryption introduced previously. To summarise, the process of encryption commences when at least one device has been authenticated. DeviceA (or master) takes the initiative and needs to determine whether to include encryption for point-to-point or broadcast communication. If DeviceB (or slave) is agreeable to the parameters offered by the master, the master proceeds to communicate further detailed information about the encryption parameters.

The actual process is invoked when the two parties agree to use encryption and then L2CAP communication terminates, where the master then sends the LMP_encryption_mode_req command. If this is acceptable to the slave, it too terminates all L2CAP communication and responds with the LMP_accepted command. The next step in this process actually determines the size of the encryption key and it is the master that sends the LMP_encryption_key_size_req command, where it offers an initial recommendation of the key size to use. The slave, in turn, then offers its own recommendation, where it informs the master what it thinks it might be capable of. Both master and slave will repeat this process until they reach an agreement; however, if neither party reaches a decision, then the LMP_not_accepted command is sent, offering the reason as unsupported parameter value (0x20), see Appendix A.

Upon accepting the key size, the LMP_accepted command is issued and the encryption procedure then takes place by issuing the LMP_start_encryption_req commnd with a random number, which is used to calculate the encryption key. Table 2-28 summarises the available commands for the encryption process.

The following sections now look at the various security level modes available for devices wishing to authenticate, although a device wishing to initiate authentication against another device must be at least in Security Modes 1 or 2.

At this level, a device will not initiate an authentication process—specifically, the following LMP commands are never issued:

LMP_in_rand, LMP_au_rand and LMP_encryption_mode_req. Authentication is optional for devices that offer this level of security.

The Service Level Enforced Security tends to be moderated through the specific channel or application, providing flexibility for various applications that may be executed concurrently. As such, no security enforcement is made until the channel establishment process has been completed or at least initiated; see Section 2.6.2, Channel Establishment.

Security Mode 2 is mandatory if more than one other security mode is available, excluding support for Security Mode 1.

The requirements of the security process in this mode are categorised as authorisation: determining whether DeviceA is permitted to access the services available through DeviceB; authentication: performed by verifying the device by means of a Bluetooth passkey; and encryption: securing the data on the physical link.

The Link Level Enforced Security is the highest available security method available to a Bluetooth-enabled device, although providing limited discoverability and non-connectable modes offer additional security where limited or unwanted access is required.

Security Mode 3 is mandatory if more than one other security mode is available, excluding support for Security Mode 1.

The paging device issues the LMP_host_connection_req command since it is interested in establishing a relationship with DeviceB. However, prior to completing the connection establishment of the two devices, the LMP Pairing, LMP Authentication and encryption procedures are all executed, ensuring that all security measures have been put in place. Failure to meet with these requirements will result in the LMP_not_accepted command being issued offering the reason of authentication failure (0x05), see Appendix A, and the connection terminating.

When the devices have agreed and reached a point where no further security measures are required, both parties then issue the LMP_setup_complete command and the initial data packet can then be transmitted. Table 2-29 summarises the available commands for connection establishment.