Bluetooth Core Specification

The notation used in the message sequence charts (MSCs) consists of ovals, elongated hexagons, boxes, lines, and arrows. The vertical lines terminated on the top by a shadow box and at the bottom by solid oval indicate a protocol entity that resides in a device. MSCs describe interactions between these entities and states those entities may be in.

The following symbols represent interactions and states:

Some message sequences are split into several charts. In these charts, numbers indicate normal or required ordering and letters represent alternative paths. For example, Step 4 is after Step 3, and Step 5a could be executed instead of Step 5b.

The protocol entities represented in the example shown in Figure 1.1 illustrate the interactions of two devices named A and B. Each device includes a Host and a LM entity in this example. Other MSCs in this Part may show the interactions of more than two devices.

Figure 1.1: Example MSC

Many of the message sequences in this Part use HCI commands or events that have enhanced or extended variants that were added to the specification later than the relevant sequence. Such variants can be related commands or events with different names (e.g., HCI_Flush and HCI_Enhanced_Flush commands) or commands or events with multiple versions (e.g., HCI_Encryption_Change event). In some instances (for example, see [Vol 4] Part E, Section 3.1.1), a Host is required to use the new variant rather than the one shown in the MSC. Even when this is not a requirement, Host implementers may prefer to use the newer variants.

In these circumstances, the MSCs have not been rewritten to use newer features but have been left unchanged. In general, the new commands and events will directly replace the old ones, but this is not always the case and readers should not assume it.

The service Remote Name Request is used to find out the name of the remote device without requiring an explicit ACL connection.

Step 1: The Host sends an HCI_Set_­Event_­Mask with the bit of Remote Host Supported Features Notification event (bit 60) set and an HCI_Remote_­Name_­Request command expecting that its local device will automatically try to connect to the remote device. (See Figure 2.1.)

Figure 2.1: Remote name request

Step 2a: If an ACL connection does not exist device A pages device B. After the Baseband Paging procedure, the local device attempts to get the remote device's extended features, send an HCI_Remote_­Host_­Supported_­Features_­Notification event, get the remote name, disconnect, and return the name of the remote device to the Host. (See Figure 2.2.)

Figure 2.2: Remote name request if no current Baseband connection

Step 2b: If an ACL connection exists when the request is made, then the Remote Name Request procedure will be executed like an optional service. No Paging and no ACL disconnect is done. (See Figure 2.3.)

Figure 2.3: Remote name request with Baseband connection

Inquiry is used to detect and collect nearby devices.

Step 1: The Host sends an HCI_Inquiry command. (See Figure 2.4.)

Figure 2.4: Host A starts inquiry procedure

Step 2: The Controller will start the Baseband Inquiry procedure with the specified Inquiry Access Code and Inquiry Length. When inquiry responses are received, the Controller extracts the required information and returns the information related to the found devices using one or more HCI_Inquiry_­Result events to the Host. (See Figure 2.5.)

Figure 2.5: LM-A performs inquiry and reports result

Step 3a: If the Host wishes to terminate an Inquiry, the HCI_Inquiry_­Cancel command is used to immediately stop the inquiry procedure. (See Figure 2.6.)

Figure 2.6: Host A cancels inquiry

Step 3b: If the Inquiry procedure is completed due to the number of results obtained, or the Inquiry Length has expired, an HCI_Inquiry_­Complete event is returned to the Host. (See Figure 2.7.)

Figure 2.7: LM-A terminates current inquiry

Periodic inquiry is used when the inquiry procedure is to be repeated periodically.

Step 1: The Hosts sends an HCI_Periodic_­Inquiry_­Mode command. (See Figure 2.8.)

Figure 2.8: Host A starts periodic inquiry

Step 2: The Controller will start a periodic Inquiry. In the inquiry cycle, one or several HCI_Inquiry_­Result events will be returned. (See Figure 2.9.)

Figure 2.9: LM-A periodically performs an inquiry and reports result

Step 3: An HCI_Inquiry_Complete event will be returned to the Host when the current periodic inquiry has finished. (See Figure 2.10.)

Figure 2.10: LM-A terminates current inquiry

Step 4: The periodic Inquiry can be stopped using the HCI_Exit_­Periodic_­Inquiry_­Mode command. (See Figure 2.11.)

Figure 2.11: Host A decides to exit periodic inquiry

Step 1: The Host sends an HCI_Create_Connection command to the Controller. The Controller then performs a Baseband Paging procedure with the specified BD_ADDR. (See Figure 3.2.)

Figure 3.2: Host A requests connection with device B

Step 2: Optionally, the LM may decide to exchange features.

(See Figure 3.3.)

Figure 3.3: LM-A and LM-B exchange features

Step 3: The LM on the Central will request an LMP_HOST_CONNECTION_REQ PDU. The LM on the Peripheral will then confirm that a connection is OK, and if so, what role is preferred. (See Figure 3.4)

Figure 3.4: LM-A requests Host connection

Step 4a: The remote Host rejects this connection, and the link is terminated. (See Figure 3.5.)

Figure 3.5: Device B rejects connection request

Step 4b: The remote Host accepts this connection. (See Figure 3.6.)

Figure 3.6: Device B accepts connection request

Step 4c: The remote Host accepts this connection but with the preference of being a Central. This will cause a role switch to occur before the LMP_ACCEPTED for the LMP_HOST_CONNECTION_REQ PDU is sent. (See Figure 3.7.)

Figure 3.7: Device B accepts connection requests as Central

Step 5: After the features have been exchanged and AFH support is determined to be available, the Central may at any time send an LMP_SET_AFH and LMP_CHANNEL_CLASSIFICATION_REQ PDU. (See Figure 3.8.)

Figure 3.8: LM-A starts Adaptive Frequency Hopping

Step 6: The LM will request if authentication is required. It does this by requesting the Link Key for this connection from the Host. (See Figure 3.9.)

Figure 3.9: Authentication initiated

Step 7a: If authentication is required by the higher layers and the devices to be connected do not have a common link key, a pairing procedure will be used. The LM will have requested a link key from the Host for this connection. If there is a negative reply, then a PIN code will be requested. This PIN code will be requested on both sides of the connection, and authentication performed based on this PIN code. The last step is for the new link key for this connection to be passed to the Host so that it may store it for future connections. (See Figure 3.10.)

Figure 3.10: Pairing during connection setup

Step 7b: If a common link key exists between the devices, then pairing is not needed. The LM will have asked for a link key from the Host for this connection. If this is a positive reply, then the link key is used for authentication. If the configuration parameter Authentication_Enable is set, then the authentication procedure is executed. This MSC only shows the case when Authentication_Enable is set on both sides. (See Figure 3.11.)

Figure 3.11: Authentication during connection setup

Step 8: Once the pairing or authentication procedure is successful, the encryption procedure may be started. This MSC only shows the set up of an encrypted point-to-point connection. (See Figure 3.12.)

Figure 3.12: Starting encryption during connection setup

Step 9: The LMs indicate that the connection is setup by sending LMP_SETUP_COMPLETE PDU. This will cause the Host to be notified of the new Connection_Handle, and this connection may be used to send higher layer data such as L2CAP information. (See Figure 3.13.)

Figure 3.13: LM-A and LM-B finishes connection setup

Step 10: Once the connection is no longer needed, either device may terminate the connection using the HCI_Disconnect command and LMP_DETACH message PDU. The disconnection procedure is one-sided and does not need an explicit acknowledgment from the remote LM. The use of ARQ Acknowledgment from the Baseband indicates that the remote LM has received the LMP_DETACH PDU. (See Figure 3.14.)

Figure 3.14: Host A decides to disconnect

Step 1: Authentication can be explicitly executed at any time after a connection has been established. If no Link Key is available then the Link Key is required from the Host. (See Figure 4.1.)

Figure 4.1: Authentication requested (legacy authentication)

When both devices support Secure Connections, Secure Authentication is used.

Figure 4.2: Authentication requested (secure authentication)

A flow diagram of Secure Simple Pairing between two devices is shown in Figure 4.3. The process is illustrated in 11 distinct steps. A number of these steps have a number of different options.

Figure 4.3: Secure Simple Pairing - flow diagram

4.2.1. Optional OOB information collection

If a device supports OOB information exchange, then the Host should request the C and R values from the Controller that need to be sent by OOB. It is then assumed that the Host transfers this information to the OOB system. This could occur a long time before, for example at the factory for a passive tag.

Figure 4.4: Optional OOB information collection (P-192 only)

When the Controller and Host support Secure Connections, the HCI_Read_­Local_­OOB_­Extended_­Data command is used instead of HCI_Read_­Local_­OOB_­Data.

Figure 4.5: Optional OOB information collection (P-192 and P-256)

4.2.2. Enable Secure Simple Pairing and Secure Connections

To enable Secure Simple Pairing, a device must use the HCI_Write_Simple_Pairing_Mode command. This must be done before any connections that use Secure Simple Pairing are created.

Figure 4.6: Enable Secure Simple Pairing

To configure the Controller to use Secure Connections HCI commands and events, a device must use the HCI_Write_Secure_Connections_Host_Support command. This must be done when no ACL connections are present.

Figure 4.7: Enable Secure Connections Host Support

To configure the Controller to enforce a maximum interval between packets containing a MIC (when AES-CCM encryption is used), a device must use the HCI_Write_Authenticated_Payload_Timeout command.

Figure 4.8: Set Authenticated_Payload_Timeout

4.2.4. L2CAP connection request for a secure service

Once a connection has been established between two devices, if a device requests an L2CAP connection to a service that requires authentication and encryption, then the device will start Secure Simple Pairing.

Figure 4.9: L2CAP connection request for a secure service

4.2.5. Optional OOB information transfer

Even if a Bluetooth connection has not been established between two devices, an OOB transfer can occur that transfers the Bluetooth Device Address of the device, and other OOB information for authentication. If an OOB transfer occurs, then the Host can start Secure Simple Pairing.

Figure 4.10: Optional OOB information transfer

4.2.6. Start Secure Simple Pairing

Once the Host has determined that Secure Simple Pairing should start, it issues an HCI_Authentication_Requested command to the Controller. This will cause the Controller to generate a request for a link key. If the Host has a link key for this connection, then pairing is not required, and the link key can be used immediately once it has been authenticated. Secure Simple Pairing will only be used if an HCI_Link_Key_Request_Negative_Reply command is sent from the Host to the Controller on the initiating side.

Figure 4.11: Start Secure Simple Pairing

4.2.7. IO capability exchange

To be able to determine the correct authentication algorithm to use, the input / output capabilities of the two devices are exchanged.

Figure 4.12: IO capability exchange

4.2.8. Public key exchange

Next the public keys are exchanged between the two devices. Once a device has received the public key of the peer device, it can start to calculate the Diffie Hellman Key (DHKey). This may take a long time, and should be started early, so that user interaction can hide the calculation time. The DHKey is not required until step 8.

Figure 4.13: Public key exchange

4.2.10. Numeric Comparison

The numeric comparison step will be done when both devices have output capabilities, or if one of the devices has no input or output capabilities. If both devices have output capabilities, this step requires the displaying of a user confirmation value. This value should be displayed until the end of step 8. If one or both devices do not have output capabilities, the same protocol is used but the Hosts will skip the step asking for the user confirmation. The sequence for Just Works is identical to that of Numeric Comparison with the exception that the Host will not show the numbers to the user.

Figure 4.14: Numeric Comparison authentication

4.2.11. Numeric Comparison failure on initiating side

If the numeric comparison fails on the initiating side due to the user indicating that the confirmation values do not match, Secure Simple Pairing is terminated.

Figure 4.15: Numeric Comparison authentication (failure on initiating side)

4.2.12. Numeric Comparison failure on responding side

If the numeric comparison fails on the responding side due to the user indicating that the confirmation values do not match, Secure Simple Pairing is terminated.

Figure 4.16: Numeric Comparison failure on responding side

4.2.13. Passkey Entry

The Passkey Entry step is used in two cases: when one device has numeric input only and the other device has either a display or numeric input capability or when both devices only have numeric input capability. In this step, one device display a number to be entered by the other device or the user enters a number on both devices. This number should be displayed until the end of step 8. Key press notification messages are shown during the user input phase.

Figure 4.17: Passkey Entry authentication

4.2.14. Passkey Entry failure on responding side

If the Passkey Entry fails on the responding side, Secure Simple Pairing is terminated.

Figure 4.18: Passkey Entry failure on responding side

4.2.15. Passkey Entry failure on initiator side

If the Passkey Entry fails on the initiating side, Secure Simple Pairing is terminated. This is only possible if the initiating LM side sends an HCI_User_Passkey_Request event.

Figure 4.19: Passkey Entry failure on initiating side

4.2.16. Out of Band

The OOB authentication will only be done when both devices have some OOB information to use. This step requires no user interaction.

Figure 4.20: OOB authentication (P-192)

Figure 4.21: OOB authentication (P-256)

4.2.17. OOB failure on initiator side

If the initiating side does not have OOB information, Secure Simple Pairing is terminated.

Figure 4.22: OOB authentication failure on initiating side

4.2.18. DHKey checks

Once the devices have been authenticated, and the DHKey calculation has completed, the DHKey value generated is checked. If this succeeds, then both devices would have finished displaying information to the user about the process, and therefore a message is sent from the Controller to the Host to notify it to stop displaying this information.

Figure 4.23: DHKey checks

4.2.19. Calculate link key

Once Secure Simple Pairing is complete, the link key can be calculated from the DHKey and used as input to a standard mutual authentication. Once this is complete, an HCI_Link_Key_Notification event will be generated.

Figure 4.24: Calculate link key

4.2.20. Enable encryption

Once the link key has been notified to the Host, the HCI_Authentication_Requested command will complete with an HCI_Authentication_Complete event. The Host can then turn on encryption using the standard methods.

Figure 4.25: Start encryption

4.2.21. L2CAP connection response

If this Secure Simple Pairing was triggered by an L2CAP Connection Request, then only after all of the above steps have completed can the L2CAP Connection Response message be sent.

Figure 4.26: L2CAP Connection Response

4.2.22. LMP ping

When the Authenticated Payload Timeout has nearly expired, the Link Manager will force the remote device to send a packet containing a MIC by sending the LMP_PING_REQ PDU.

Figure 4.27: Successful ping

When a packet with a MIC has not been received within the Authenticated Payload Timeout, the Host is notified that the timer has expired.

Figure 4.28: Unsuccessful ping

When enabled by the Host, the Peripheral generates an HCI_Link_­Supervision_­Timeout_­Changed event after the LMP_­SUPERVISION_­TIMEOUT PDU is received.

Figure 4.29: Link supervision timeout event

Step 1: The Host may at any time turn on encryption using the HCI_Set_­Connection_­Encryption command. This command can be originated from either the Central or Peripheral sides. Only the Central side is shown in Figure 4.30. If this command is sent from a Peripheral, the only difference is that the LMP_ENCRYPTION_­MODE_­REQ PDU will be sent from the Peripheral. The LMP_ENCRYPTION_­KEY_­SIZE_­REQ and LMP_START_­ENCRYPTION_­REQ PDUs will always be requested from the Central. (See Figure 4.30.)

Figure 4.30: Encryption requested

Step 2: To terminate the use of encryption, the HCI_Set_Connection_Encryption command is used. (See Figure 4.31.)

Figure 4.31: Encryption off requested

Step 1: The Central’s Host (Host A) may change the connection link key using the HCI_Change_Connection_Link_Key command. A new link key will be generated and the Hosts will be notified of this new link key. (See Figure 4.32.)

Figure 4.32: Change connection link key

Step 1: The Central’s Host (Host A) may change the connection link key using the HCI_Change_Connection_Link_Key command. A new link key will be generated and the Hosts will be notified of this new link key. Encryption will then be paused and resumed, immediately using this new link key to generate a new encryption key. (See Figure 4.33.)

Figure 4.33: Change connection link key with encryption pause and resume

Step 1: The Host changes to a Temporary Link Key from a Semi-permanent Link Key using the HCI_Link_Key_Selection command when at least one device does not support Encryption Pause and Resume. (See Figure 4.34.)

Figure 4.34: Change to temporary link key

Step 2: The Host changes to a Semi-permanent Link Key from a Temporary Link Key using the HCI_Link_Key_Selection command. (See Figure 4.35.)

Figure 4.35: Change to semi-permanent link key

Using the HCI_Read_Remote_Supported_Features command the supported LMP Features of a remote device can be read. (See Figure 4.36.)

If the remote supported features have been obtained previously then the Controller may return them without sending any LMP PDUs.

Step 1: The Host requests the supported features of a remote device.

Figure 4.36: Read remote supported features

Using the HCI_Read_Remote_Extended_Features command the extended LMP features of a remote device can be read. (See Figure 4.37.)

If the remote extended features have been obtained previously then the Controller may return them without sending any LMP PDUs.

Step 1: The Host requests the extended features of a remote device.

Figure 4.37: Read remote extended features

Using the HCI_Read_Clock_Offset command the device acting as the Central can read the Clock Offset of a Peripheral (see Figure 4.38). The Clock Offset can be used to speed up the paging procedure in a later connection attempt.

Step 1: The Host requests the clock offset of a remote device.

Figure 4.38: Read clock offset (Central)

If the command is requested from the Peripheral, the Controller will directly return an HCI_Command_Status event and an HCI_Read_Clock_Offset_Complete event without sending any LMP PDUs (see Figure 4.39).

Figure 4.39: Read clock offset (Peripheral)

The HCI_Switch_Role command can be used to explicitly switch the current Central / Peripheral role of the local device with the specified device. The Central’s Host (A) requests a role switch with a Peripheral. This will first pause encryption, and then send the switch request, and the Peripheral will respond with the slot offset and accepted. The role switch is performed by doing the TDD switch and piconet switch. Encryption is resumed, and finally an HCI_Role_Change event is sent on both sides. (See Figure 4.40.)

Figure 4.40: Role switch on an encrypted link using encryption pause and resume

The HCI_Refresh_Encryption_Key command may be used by the Central's Host to explicitly pause and resuming encryption to refresh the encryption key. After encryption is resumed an HCI_Encryption_Key_Refresh_Complete event is sent on both sides. (See Figure 4.41).

Figure 4.41: Refreshing encryption keys (E0)

When both devices support Secure Connections, the encryption key refresh sequence is performed as follows.

Figure 4.42: Refreshing encryption keys (AES-CCM)

Using the HCI_Read_Remote_Version_Information command the version information of a remote device can be read. (See Figure 4.43.)

If the remote version information has been obtained previously then the Controller may return them without sending any LMP PDUs.

Step 1: The Host requests the version information of a remote device.

Figure 4.43: Read remote version information

Using the HCI_Flow_Specification command the Quality of Service (QoS) and Flow Specification requirements of a connection can be notified to a Controller. The Controller may then change the quality of service parameters with a remote device. (See Figure 4.44.)

Step 1: The Host sends QoS parameters to a remote device.

Figure 4.44: QoS flow specification

The HCI_Switch_Role command can be used to explicitly switch the current Central / Peripheral role of the local device with the specified device.

Step 1a: The Central’s Host (A) requests a role switch with a Peripheral. This will send the switch request, and the Peripheral will respond with the slot offset and accepted. (See Figure 4.45.)

Figure 4.45: Central requests role switch

Step 1b: The Peripheral’s Host (B) requests a role switch with a Central. This will send the slot offset and the switch request, and the Central will respond with a LMP_ACCEPTED PDU. (See Figure 4.46.)

Figure 4.46: Peripheral requests role switch

Step 2: The role switch is performed by doing the TDD switch and piconet switch. Finally an HCI_Role_Change event is sent on both sides. (See Figure 4.47.)

Figure 4.47: Role switch is performed

Step 1: The setup of SAM may be triggered by the Link Manager for MWS coexistence or topology management purposes. SAM setup may be triggered by HCI commands as shown in Figure 4.48 or by the real-time signals (e.g. MWS_PATTERN_Index, FRAME_SYNC, etc.) from the Coexistence Logical Interface (see [Vol 7] Part A ).

Piconet Clock Adjustment may be performed to create more available slot pairs per MWS frame.

Figure 4.48: SAM configuration setup on device A

Step 2: The Link Manager on device A sends the SAM configuration to device B and then selects a SAM map (see Figure 4.49).

Figure 4.49: SAM configuration transmitted to device B

Step 3: Device A receives a new configuration (possibly over HCI), sends it to device B, and switches to using it (see Figure 4.50).

Figure 4.50: SAM configuration change

The Link Managers of both the Central and Peripheral may initiate the same LMP transaction at the same time.

Figure 4.51: LMP transaction collision

Using the HCI_Setup_Synchronous_Connection command, a Host can add a synchronous logical channel to the link. A synchronous logical link can be provided by creating a SCO or an eSCO logical transport.

Step 1a: Central requests a synchronous connection with a device. (See Figure 5.1.)

Figure 5.1: Central requests synchronous EV3, EV4, or EV5 connection

Step 1b: Peripheral requests a synchronous connection with a device. (See Figure 5.2.)

Figure 5.2: Peripheral requests synchronous EV3, EV4, or EV5 connection

Step 1c: Central requests a SCO connection with a device. (See Figure 5.3.)

Figure 5.3: Central requests synchronous connection using SCO

Step 1d: Central requests a SCO connection with a device. (See Figure 5.4.)

Figure 5.4: Central requests synchronous connection with legacy Peripheral

Step 1e: Host device requests a SCO connection with a device. (See Figure 5.5.)

Figure 5.5: Any device that supports only SCO connections requests a synchronous connection with a device

Step 2a: Central renegotiates eSCO connection (see Figure 5.6.)

Figure 5.6: Central renegotiates eSCO connection

Step 2b: Peripheral renegotiates eSCO connection (see Figure 5.7.)

Figure 5.7: Peripheral renegotiates eSCO connection

Step 3a: eSCO disconnection. (See Figure 5.8.)

Figure 5.8: Synchronous disconnection of eSCO connection

Step 3b: SCO disconnection. (See Figure 5.9.)

Figure 5.9: Synchronous disconnection of SCO connection

Using the HCI_Enhanced_Setup_Synchronous_Connection command, a Host can add a synchronous logical channel to the link. A synchronous logical link can be provided by creating a SCO or an eSCO logical transport.

Step 1a: Central requests a synchronous connection with a Peripheral.

Figure 5.10: Central requests synchronous connection (EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV3, or 3-EV5)

Step 1b: Peripheral requests a synchronous connection with a Central.

Figure 5.11: Peripheral requests synchronous connection (EV3, EV4, EV5, 2-EV3, 2-EV5, 3-EV3, or 3-EV5)

Step 1c : Central requests a SCO connection with a Peripheral.

Figure 5.12: Central requests synchronous connection (HV1, HV2, HV3, EV3, EV4, EV5, 2EV3, 2EV5, 3EV3, or 3EV5)

Step 1d : Peripheral requests a SCO connection with a Central.

Figure 5.13: Peripheral requests synchronous connection (HV1, HV2, or HV3)

Step 2a: Central renegotiates eSCO connection.

Figure 5.14: Central renegotiates synchronous connection parameter change

Step 2b: Peripheral renegotiates eSCO connection.

Figure 5.15: Peripheral renegotiates synchronous connection parameter change

The HCI_Sniff_Mode command is used to enter Sniff mode. The HCI_Exit_Sniff_Mode command is used to exit Sniff mode.

Step 1: Host requests to enter Sniff mode. Multiple LMP_SNIFF_REQ PDUs may be sent as the parameters for Sniff mode are negotiated. (See Figure 6.1.)

Figure 6.1: Sniff mode request

Step 2: Host requests to exit Sniff mode. (See Figure 6.2.)

Figure 6.2: Exit Sniff mode request

The HCI_Hold_Mode command can be used to place a device into Hold mode. The Controller may do this by either negotiating the Hold mode parameters or forcing Hold mode. Hold mode will automatically end after the negotiated length of time.

Step 1a: A Host requests Hold mode. (See Figure 6.3.)

Figure 6.3: Hold request

Step 1b: A Host may force Hold mode. (See Figure 6.4.)

Figure 6.4: Central forces Hold mode

Step 1c: A Peripheral requests Hold mode. (See Figure 6.5.)

Figure 6.5: Peripheral forces Hold mode

Step 2: When Hold mode completes the Hosts are notified using the HCI_Mode_Change event. (See Figure 6.6.)

Figure 6.6: Hold mode completes

The Local Loopback mode is used to loopback received HCI commands, and HCI ACL Data and HCI Synchronous Data packets sent from the Host to the Controller.

Step 1: The Host enters Local Loopback mode. Four HCI_Connection_Complete events are generated and then an HCI_Command_Complete event. (See Figure 8.1.)

Figure 8.1: Entering Local Loopback mode

Step 2a: The Host sending HCI Data packet will receive the exact same data back in HCI Data packets from the Controller. (See Figure 8.2.)

Figure 8.2: Looping back data in Local Loopback mode

Step 2b: The Host sending most HCI Command packets to the Controller will receive an HCI_Loopback_Command event with the contents of the HCI Command packet in the payload. (See Figure 8.3.)

Figure 8.3: Looping back commands in Local Loopback mode

Step 3: The Host exits Local Loopback mode. Multiple HCI_Disconnection_Complete events are generated before the HCI_Command_Complete event. (See Figure 8.4.)

Figure 8.4: Exiting Local Loopback mode

The Remote Loopback mode is used to loopback data to a remote device over the air.

Step 1: The local device first enables remote loopback. The remote Host then sets up a connection to the local device. (See Figure 8.5.)

Figure 8.5: Entering Remote Loopback mode

Step 2: Any data received from the remote Host will be looped back in the Controller of the local device. (See Figure 8.6.)

Figure 8.6: Looping back data in Remote Loopback mode

Step 3: The local Host exits Remote Loopback mode. Any connections can then be disconnected by the remote device. (See Figure 8.7.)

Figure 8.7: Exiting Remote Loopback mode