Skip to main content

Bluetooth Core Specification

Part C. Generic Access Profile

vAtlanta r00

This profile defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to use of different security levels. In addition, this profile includes common format requirements for parameters accessible on the user interface level.

1. Foreword

Interoperability between devices from different manufacturers is provided for a specific service and use case, if the devices conform to a Bluetooth SIG- defined profile specification. A profile defines a selection of messages and procedures (generally termed capabilities) from the Bluetooth SIG specifications and gives a description of the air interface for specified service(s) and use case(s).

Whether the provision of a feature is mandatory or optional is stated separately for both sides of the Bluetooth air interface.

1.1. Scope

The purpose of the Generic Access Profile is:

To introduce definitions, recommendations and common requirements related to modes and access procedures that are to be used by transport and application profiles.

To describe how devices are to behave in standby and connecting states in order to avoid situations where links and channels cannot be established between Bluetooth devices or that prevent multi-profile operation. Special focus is put on discovery, link establishment and security procedures.

To state requirements on user interface aspects, mainly coding schemes and names of procedures and parameters, that are needed to provide a satisfactory user experience.

This profile defines three implementation transport types based on the supported Core Configurations as defined in [Vol 0] Part D, Section 2. These implementation transport types are defined in Table 1.1:

Implementation Transport Type

Description

BR/EDR-only

Implementations of a BR/EDR Core Configuration (see [Vol 0] Part D, Section 2.1.1, [Vol 0] Part D, Section 2.2.1, and [Vol 0] Part D, Section 2.3.1)

LE only

Implementations of an LE Core Configuration (see [Vol 0] Part D, Section 2.1.2, [Vol 0] Part D, Section 2.2.2, and [Vol 0] Part D, Section 2.3.2)

BR/EDR/LE

Implementations of a BR/EDR/LE Core Configuration (see [Vol 0] Part D, Section 2.1.3, [Vol 0] Part D, Section 2.2.3, and [Vol 0] Part D, Section 2.3.3)

Table 1.1: Implementation transport types


The terms physical transport, physical link and physical channel as defined in [Vol 1] Part A, Section 3 are used in the specification.

1.2. Symbols and conventions
1.2.1. [This section is no longer used]
1.2.2. Signaling diagram conventions

The arrows shown in Figure 1.1 are used in diagrams describing procedures:

Arrows used in signaling diagrams
Figure 1.1: Arrows used in signaling diagrams


In Figure 1.1, the following cases are shown: PROC1 is a sub-procedure initiated by B. PROC2 is a sub-procedure initiated by A. PROC3 is a sub-procedure where the initiating side is undefined (may be both A or B). Dashed arrows denote optional steps. PROC4 indicates an optional sub-procedure initiated by A, and PROC5 indicates an optional sub-procedure initiated by B.

MSG1 is a message sent from B to A. MSG2 is a message sent from A to B. MSG3 indicates an optional message from A to B.

1.2.3. Notation for timers and counters

Timers are introduced specific to this profile. To distinguish them from timers used in the Bluetooth protocol specifications and other profiles, these timers are named in the following format: ’TGAP(nnn)’.

1.2.4. Notation for UUIDs

The use of « » (e.g. «Device Name») indicates a Bluetooth SIG-defined UUID.

1.3. GAP requirements

The sections of GAP that apply to an implementation depend on which Core-Host Configuration or Core-Complete Configuration (see [Vol 0] Part D, Section 2) it implements, as shown in Table 1.2.

Core Configuration

Applicable sections

BR/EDR

1 to 8, 12, 15 to 17, Appendices A and B

LE

1 to 3, 9 to 12, 15 to 17, Appendices A and B

BR/EDR/LE

All

Table 1.2: Required sections for each Core Configuration


2. Profile overview

2.1. Profile stack
Relationship of GAP with lower layers of the Bluetooth architecture
Figure 2.1: Relationship of GAP with lower layers of the Bluetooth architecture


The purpose of this profile is to describe:

  • Profile roles

  • Discoverability modes and procedures

  • Connection modes and procedures

  • Security modes and procedures

2.2. Profile roles
2.2.1. Roles when operating over BR/EDR Physical Transport

In GAP, for describing the Bluetooth communication that occurs between two devices in the BR/EDR GAP role, the generic notation of the A-party (the paging device in case of link establishment, or initiator in case of another procedure on an established link) and the B-party (paged device or acceptor) is used. The A-party is the one that, for a given procedure, initiates device discovery, initiates the establishment of a physical link or initiates a transaction on an existing link.

This profile handles the procedures between two devices related to discovery and connecting (link and connection establishment) for the case where none of the two devices has any link established as well as the case where (at least) one device has a link established (possibly to a third device) before starting the described procedure.

This profile covers procedures initiated by one device (A) towards another device (B) whether or not they have an existing Bluetooth link active
Figure 2.2: This profile covers procedures initiated by one device (A) towards another device (B) whether or not they have an existing Bluetooth link active


The initiator and the acceptor generally operate the generic procedures according to this profile or another profile referring to this profile. If the acceptor operates according to several profiles simultaneously, this profile describes generic mechanisms for how to handle this.

2.2.2. Roles when operating over an LE physical transport

There are four GAP roles defined for devices operating over an LE physical transport:

  • Broadcaster

  • Observer

  • Peripheral

  • Central

The GAP roles "Central" and "Peripheral" are related to, but not the same as, the Link Layer roles with the same names and therefore can have different requirements. If a connection is established successfully, the device with one of these GAP roles will also have the corresponding Link Layer role. However, the device can be in the GAP role without a connection being established.

Table 2.1 defines requirements for physical layer and Link Layer functionalities for each GAP role when operating over an LE physical transport.

GAP Roles When Operating Over an

LE Physical Transport

Broadcaster

Observer

Peripheral

Central

Physical layer functionality:

  • Transmitter characteristics

M

O

M

M

  • Receiver characteristics

O

M

M

M

Link Layer functionality:

States:

  • Standby state

M

M

M

M

  • Advertising state

M

E

M

E

  • Scanning state

E

M

E

M

  • Initiating state

E

E

E

M

  • Synchronization State

E

O

E

E

  • Isochronous Broadcasting State

O

E

E

E

  • Connection state

Peripheral role

E

E

M

E

Central role

E

E

E

M

Advertising event types:

  • Connectable and scannable undirected event

E

E

M

E

  • Connectable undirected event1

E

E

O

E

  • Connectable directed event

E

E

O

E

  • Non-connectable and non-scannable undirected event

M

E

O

E

  • Non-connectable and non-scannable directed event1

O

E

O

E

  • Scannable undirected event

O

E

O

E

  • Scannable directed event1

O

E

O

E

Scanning type:

  • Passive scanning

E

M

E

O

  • Active scanning

E

O

E

C.1

Link Layer control procedures:

  • Connection Update procedure

E

E

M

M

  • Channel Map Update procedure

E

E

M

M

  • Encryption procedure

E

E

O

O

  • Central-initiated Feature Exchange procedure

E

E

M

M

  • Peripheral-initiated Feature Exchange procedure

E

E

C.2

C.2

  • Connection Parameters Request procedure

E

E

O

O

  • Version Exchange procedure

E

E

M

M

  • ACL Termination procedure

E

E

M

M

  • LE Ping procedure

E

E

O

O

  • Data Length Update procedure

E

E

O

O

  • PHY Update procedure

E

E

O

O

  • Minimum Number Of Used Channels procedure

E

E

O

O

  • Periodic Advertising Sync Transfer procedure

E

E

O

O

  • Connected Isochronous Stream Creation procedure

E

E

O

O

  • Connected Isochronous Stream Termination procedure

E

E

O

O

Broadcast control procedures:

  • Broadcast Isochronous Channel Map Update procedure

O

O

E

E

  • Broadcast Isochronous Termination procedure

O

O

E

E

C.1:

Optional if passive scanning is supported, otherwise mandatory.

C.2:

Mandatory if Connection Parameters Request procedure is supported, otherwise optional.

1These advertising event types are excluded if the device does not support LE Extended Advertising.

Table 2.1: GAP requirements for physical layer and Link Layer functionalities for each GAP role when operating over an LE physical transport


2.2.2.1. Broadcaster role

A device operating in the Broadcaster role is a device that sends advertising events or periodic advertising events as described in [Vol 6] Part B, Section 4.4.2, and may also send Broadcast Isochronous Stream (BIS) events as described in [Vol 6] Part B, Section 4.4.6. A device operating in the Broadcaster role is referred to as a Broadcaster and shall have a transmitter and may have a receiver.

2.2.2.2. Observer role

A device operating in the Observer role is a device that receives advertising events or periodic advertising events as described in [Vol 6] Part B, Section 4.4.3, and may also receive BIS events as described in [Vol 6] Part B, Section 4.4.6. A device operating in the Observer role is referred to as an Observer and shall have a receiver and may have a transmitter.

2.2.2.3. Peripheral role

Any device that accepts the establishment of an LE active physical link using any of the connection establishment procedures as defined in Section 9 is referred to as being in the Peripheral role. A device operating in the Peripheral role will be in the Peripheral role in the Link Layer Connection state as described in [Vol 6] Part B, Section 4.5. A device operating in the Peripheral role is referred to as a Peripheral. A Peripheral shall have both a transmitter and a receiver.

2.2.2.4. Central role

A device that supports the Central role initiates the establishment of an LE active physical link. A device operating in the Central role will be in the Central role in the Link Layer Connection state as described in [Vol 6] Part B, Section 4.5. A device operating in the Central role is referred to as a Central. A Central shall have both a transmitter and a receiver.

2.2.2.5. Concurrent operation in multiple GAP roles

A device may operate in multiple GAP roles concurrently if supported by the Controller. The Host should read the supported Link Layer states and state combinations from the Controller before any procedures or modes are used.

2.3. User requirements and scenarios

The Bluetooth user should, where expected, be able to connect a Bluetooth device to any other Bluetooth device. Even if the two connected devices don’t share any common application, it should be possible for the user to find this out using basic Bluetooth capabilities. When the two devices do share the same application but are from different manufacturers, the ability to connect them should not be blocked just because manufacturers choose to call basic Bluetooth capabilities by different names on the user interface level or implement basic procedures to be executed in different orders.

2.4. Profile fundamentals

This profile states the requirements on names, values and coding schemes used for names of parameters and procedures experienced on the user interface level.

This profile defines modes of operation that are not service- or profile-specific, but that are generic and can be used by profiles referring to this profile, and by devices implementing multiple profiles.

This profile defines the general procedures that can be used for discovering identities, names and basic capabilities of other Bluetooth devices that are in a mode where they can be discovered. Only procedures where no channel or connection establishment is used are specified.

This profile defines the general procedure for how to create bonds (i.e., dedicated exchange of link keys) between Bluetooth devices.

This profile describes the general procedures that can be used for establishing connections to other Bluetooth devices that are in a mode that allows them to accept connections and service requests.

2.5. [This section is no longer used]

3. User interface aspects

3.1. The user interface level

In the context of the specification, the user interface level refers to places (such as displays, dialog boxes, manuals, packaging, advertising, etc.) where users of Bluetooth devices encounters names, values and numerical representation of Bluetooth terminology and parameters.

This profile specifies the generic terms that should be used on the user interface level.

3.2. Representation of Bluetooth parameters
3.2.1. Bluetooth Device Address (BD_ADDR)
3.2.1.1. Definition

A BD_ADDR is the address used by a Bluetooth device as defined in Section 15.1. It is received from a remote device during the device discovery procedure.

3.2.1.2. Term on user interface level

When the Bluetooth address is referred to on the UI level, the term ‘Bluetooth Device Address’ should be used.

3.2.1.3. Representation

On the Baseband level the BD_ADDR is represented as 48 bits (see [Vol 2] Part B, Section 1.2). On the Link Layer the public and random device address are represented as 48-bit addresses.

On the UI level the Bluetooth address shall be represented as 12 hexadecimal characters, possibly divided into sub-parts separated by ‘:’ (e.g., ‘000C3E3A4B69’ or ‘00:0C:3E:3A:4B:69’). On the UI level any number shall have the MSB -> LSB (from left to right) ‘natural’ ordering.

3.2.2. Bluetooth Device Name (the user-friendly name)
3.2.2.1. Definition

The Bluetooth Device Name is the user-friendly name that a Bluetooth device exposes to remote devices. For a BR/EDR-only implementation, the name is a character string returned in the LMP_NAME_RES in response to an LMP_NAME_REQ. For an LE-only implementation, the name is a character string held in the Device Name characteristic as defined in Section 12.1.

3.2.2.1.1. Bluetooth Device Name in a BR/EDR/LE implementation

A BR/EDR/LE implementation shall have a single Bluetooth Device Name which shall be identical irrespective of the physical channel used to perform the name discovery procedure.

For the BR/EDR physical channel the name is received in the LMP_NAME_RES. For the LE physical channel the name can be read from the Device Name characteristic as defined in Section 12.1.

Note

Note: The Device Name Characteristic of the local device can be read by a remote device using ATT over BR/EDR if the local device supports ATT over BR/EDR.

3.2.2.2. Term on user interface level

When the Bluetooth Device Name is referred to on the UI level, the term ‘Bluetooth Device Name’ should be used.

3.2.2.3. Representation

The Bluetooth Device Name can be up to 248 bytes (see [Vol 2] Part C, Section 4.3.5). It shall be encoded according to UTF-8 (therefore the name entered on the UI level may be restricted to as few as 62 characters if codepoints outside the range U+0000 to U+007F are used).

A device cannot expect that a general remote device is able to handle more than the first 40 characters of the Bluetooth Device Name. If a remote device has limited display capabilities, it may use only the first 20 characters.

3.2.3. Bluetooth Passkey (Bluetooth PIN)
3.2.3.1. Definition

The Bluetooth Passkey may be used to authenticate two Bluetooth devices with each other during the creation of a mutual link key via the pairing procedure. The passkey may be used in the pairing procedures to generate the initial link key.

The PIN may be entered on the UI level but may also be stored in the device; e.g., in the case of a device without an interface for entering and displaying digits.

3.2.3.2. Terms at user interface level

When the Bluetooth PIN is referred to on the UI level, the term ‘Bluetooth Passkey’ should be used.

3.2.3.3. Representation

There are a number of different representations of the Bluetooth Passkey. At a high level there are two distinct representations: one used with the Secure Simple Pairing and Security Manager, and another used with legacy pairing (where it is generally referred to as the Bluetooth PIN).

For Secure Simple Pairing and Security Manager, the Bluetooth Passkey is a 6-digit numerical value. It is represented as integer value in the range 0x00000000 – 0x000F423F (000000 to 999999). The numeric value may be used as the input to the Authentication stage 1 for Secure Simple Pairing Passkey Entry (see [Vol 2] Part H, Section 7.2.3), or as the TK value in the Security Manager for the process defined in [Vol 3] Part H, Section 2.3.5.

For legacy pairing (see Section B.2), the Bluetooth PIN has different representations on different levels. PINBB is used on the Baseband level, and PINUI is used on the user interface level. PINBB is the PIN used in [Vol 2] Part H, Section 3.2.1 for calculating the initialization key during the Pairing procedure.

PINUI is the character representation of the PIN that is entered on the UI level. The transformation from PINUI to PINBB shall be according to UTF-8. PINBB may be 128 bits (16 bytes).

PIN codes may be up to 16 characters. In order to take advantage of the full level of security all PINs should be 16 characters long. Variable PINs should be composed of alphanumeric characters chosen from within the Unicode range U+0000 to U+007F. If the PIN contains any decimal digits these shall be encoded using the Unicode Basic Latin characters (i.e., U+0030 to U+0039) (Note 1).

For compatibility with devices with numeric keypads, fixed PINs shall be composed of only decimal digits, and variable PINs should be composed of only decimal digits.

If a device supports entry of characters outside the Unicode range U+0000 to U+007F, other Unicode code points may be used (Note 2), except the Halfwidth and Fullwidth Forms (i.e., U+FF00 to U+FFEF) shall not be used (Note 3).

Examples:

User-entered code

Corresponding PINBB[0..length-1]

(value as a sequence of octets in hexadecimal notation)

’0196554200906493’

length = 16, value = 0x30 0x31 0x39 0x36 0x35 0x35 0x34 0x32 0x30 0x30 0x39 0x30 0x36 0x34 0x39 0x33

’Børnelitteratur’

length = 16, value = 0x42 0xC3 0xB8 0x72 0x6E 0x65 0x6C 0x69 0x74 0x74 0x65 0x72 0x61 0x74 0x75 0x72

Note

Note 1: This is to prevent interoperability problems since there are decimal digits at other code points (e.g., the Fullwidth digits at code points U+FF10 to U+FF19).

Note

Note 2: Unicode characters outside the Basic Latin range (U+0000 to U+007F) encode to multiple bytes; therefore, when characters outside the Basic Latin range are used the maximum number of characters in the PINUI will be less than 16. The second example illustrates a case where a 15 character string encodes to 16 bytes because the character ø is outside the Basic Latin range and encodes to two bytes (0xC3 0xB8).

Note

Note 3: This is to prevent interoperability problems since the Halfwidth and Fullwidth forms contain alternative variants of ASCII, Katakana, Hangul, punctuation and symbols. All of the characters in the Halfwidth and Fullwidth forms have other related Unicode characters; for example, U+3150 (Hangul Letter AE) can be used instead of U+FFC3 (Halfwidth Hangul Letter AE).

3.2.4. Class of Device
3.2.4.1. Definition

Class of Device is a parameter received during the device discovery procedure on the BR/EDR physical transport, indicating the type of device. The Class of Device parameter is only used on BR/EDR and BR/EDR/LE devices using the BR/EDR physical transport.

3.2.4.2. Term on user interface level

The information within the Class of Device parameter should be referred to as ‘Bluetooth Device Class’ (i.e., the major and minor device class fields) and ‘Bluetooth Service Type’ (i.e., the service class field). The terms for the defined Bluetooth Device Classes and Bluetooth Service Types are defined in [3].

When using a mix of information found in the Bluetooth Device Class and the Bluetooth Service Type, the term ‘Bluetooth Device Type’ should be used.

3.2.4.3. Representation

The Class of Device is a bit field and is defined in [3]. The UI-level representation of the information in the Class of Device is implementation specific.

3.2.4.4. Usage

Some devices provide more than one service and a given service may be provided by different device types. Therefore, the device type does not have a one-to-one relationship with services supported. The major and minor device class field should not be used to determine whether a device supports any specific service(s). It may be used as an indication of devices that are most likely to support desired services before service discovery requests are made, and it may be used to guide the user when selecting among several devices that support the same service.

3.2.5. Appearance characteristic
3.2.5.1. Definition

The Appearance characteristic contains a 16-bit number that can be mapped to an icon or string that describes the physical representation of the device during the device discovery procedure. It is a characteristic of the GAP service located on the device’s GATT Server. See Section 12.2.

3.2.5.2. Usage at user interface level

The Appearance characteristic value should be mapped to an icon or string or something similar that conveys to the user a visual description of the device. This allows the user to determine which device is being discovered purely by visual appearance. If a string is displayed, this string should be translated into the language selected by the user for the device.

3.2.5.3. Representation

The Appearance characteristic value shall be set to one of the 16-bit numbers assigned by the Bluetooth SIG and defined in Section 1.12 of [4]. The UI-level representation of the Appearance characteristic value is implementation specific.

3.2.6. Broadcast Code
3.2.6.1. Definition

The Broadcast_Code parameter is used to support an encrypted BIG. It is used in the process of encrypting the data in the transmission of an encrypted BIG and in the process of decrypting the data in the reception of a BIS within that BIG.

3.2.6.2. Terms at user interface level

When the Broadcast_Code parameter is referred to on the UI level, the term ‘Bluetooth Privacy Code’ should be used.

3.2.6.3. Representation

The Broadcast_Code parameter has different representations on different levels.

On the UI level, the Broadcast Code parameter shall be represented as a string of at least 4 octets that meets the requirements in Section 3.2.3.3 for a PINUI (e.g., it is not more than 16 octets when represented in UTF-8). 16 octets should be used for higher level of security.

On all levels other than UI, the Broadcast Code parameter shall be represented as a 128-bit value. The transformation from string to number shall be by representing the string in UTF-8, placing the resulting bytes in 8-bit fields of the value starting at the least significant bit, and then padding with zeros in the most significant bits if necessary. For example, the string “Børne House” is represented as the value 0x00000000_6573756F_4820656E_72B8C342.

3.3. Pairing

Pairing over a BR/EDR physical link is defined on LMP level (LMP pairing, see Section B.2). Pairing over an LE physical link is defined by the Security Manager specification ([Vol 3] Part H, Section 2.3). Either the user initiates the bonding procedure and enters the passkey with the explicit purpose of creating a bond (and maybe also a secure relationship) between two Bluetooth devices, or the user is requested to enter the passkey during the establishment procedure since the devices did not share a common link key beforehand. In the first case, the user is said to perform “bonding (with entering of passkey)” and in the second case the user is said to “authenticate using the passkey.”

4. Modes – BR/EDR physical transport

Group

Ref.

Mode

Support

Discoverability modes:

4.1

Non-discoverable

C.1

Limited discoverable

O

General discoverable

O

Connectability modes:

4.2

Non-connectable

O

Connectable

M

Bondable modes:

4.3

Non-bondable

C.4

Bondable

C.2

Synchronizability modes:

4.4

Non-synchronizable

M

Synchronizable

C.5

C.1:

Mandatory if limited discoverable mode is supported or general discoverable mode is not supported, otherwise optional.

C.2:

Mandatory if the bonding procedure is supported, otherwise optional.

C.4:

Optional if Bondable mode is supported, otherwise mandatory.

C.5:

Mandatory if the Synchronization Train procedure is supported, otherwise excluded.

Table 4.1: Conformance requirements related to modes defined in this section


4.1. Discoverability modes

With respect to inquiry, a Bluetooth device shall be either in non-discoverable mode or in a discoverable mode. (The device shall be in one, and only one, discoverability mode at a time.) The two discoverable modes defined here are called limited discoverable mode and general discoverable mode. Inquiry is defined in [Vol 2] Part B, Section 8.4.

When a Bluetooth device is in non-discoverable mode it does not respond to inquiry.

A Bluetooth device is said to be made discoverable, or set into a discoverable mode, when it is in limited discoverable mode or in general discoverable mode. Even when a Bluetooth device is made discoverable, it may be unable to respond to inquiry due to other Baseband activity (for example, reserved synchronous slots should have priority over response packets, so that synchronous links may prevent a response from being returned). A Bluetooth device that does not respond to inquiry is called a silent device.

After being made discoverable, the Bluetooth device shall be discoverable for at least TGAP(103).

The speed of discovery is dependent on the configuration of the inquiry scan interval and inquiry scan type of the Bluetooth device. The Host is able to configure these parameters based on trade-offs between power consumption, bandwidth and the desired speed of discovery.

4.1.1. Non-discoverable mode
4.1.1.1. Definition

When a Bluetooth device is in non-discoverable mode, it shall never enter the INQUIRY_SCAN state.

4.1.1.2. Term on UI-level

Bluetooth device is ‘non-discoverable’ or in ’non-discoverable mode’.

4.1.2. Limited Discoverable mode
4.1.2.1. Definition

The limited discoverable mode should be used by devices that need to be discoverable only for a limited period of time, during temporary conditions, or for a specific event.

There are two common reasons to use limited discoverable mode:

  • Limited discoverable mode can be used to allow remote devices using the general inquiry procedure to prioritize or otherwise identify devices in limited discoverable mode when presenting discovered devices to the end user because, typically, the user is interacting with them.

  • Limited discoverable mode can also be used to allow remote devices using the limited inquiry procedure to filter out devices using the general discoverable mode.

A Bluetooth device should not be in limited discoverable mode for more than TGAP(104). The scanning for the limited inquiry access code can be done either in parallel or in sequence with the scanning of the general inquiry access code. When in limited discoverable mode, one of the following options shall be used.

  • Parallel scanning

    When a Bluetooth device is in limited discoverable mode and when discovery speed is more important than power consumption or bandwidth, it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(105) and that Interlaced Inquiry scan is used.

    If, however, power consumption or bandwidth is important, but not critical, it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(102) and Interlaced Inquiry scan is used.

    When power consumption or bandwidth is critical it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(102) and Non-interlaced Inquiry scan is used.

    In all cases the Bluetooth device shall enter the INQUIRY_SCAN state at least once in TGAP(102) and scan for the GIAC and the LIAC for at least TGAP(101).

    When either a SCO or eSCO link is in operation, it is recommended to use interlaced scan to significantly decrease the discoverability time.

  • Sequential scanning

    When a Bluetooth device is in limited discoverable mode, it shall enter the INQUIRY_SCAN state at least once in TGAP(102) and scan for the GIAC for at least TGAP(101) and enter the INQUIRY_SCAN state more often than once in TGAP(102) and scan for the LIAC for at least TGAP(101).

    If an inquiry message is received when in limited discoverable mode, the entry into the INQUIRY_RESPONSE state takes precedence over the next entries into INQUIRY_SCAN state until the inquiry response is completed.

4.1.2.2. Conditions

When a device is in limited discoverable mode it shall set bit number 13 in the Major Service Class part of the Class of Device/Service field [3].

4.1.2.3. Term on UI-level

Bluetooth device is ‘discoverable’ or in ‘discoverable mode’.

4.1.3. General Discoverable mode
4.1.3.1. Definition

The general discoverable mode shall be used by devices that need to be

discoverable continuously or for no specific condition.

Devices in the general discoverable mode will not be discovered by devices performing the limited inquiry procedure. General discoverable mode should not be used if it is known that the device performing discovery will be using the limited inquiry procedure (see Section 6.1).

4.1.3.2. Conditions

When a Bluetooth device is in general discoverable mode and when discovery speed is more important than power consumption or bandwidth, it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(105) and that Interlaced Inquiry scan is used.

If, however, power consumption or bandwidth is important, but not critical, it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(102) and Interlaced Inquiry scan is used.

When power consumption or bandwidth is critical it is recommended that the Bluetooth device enter the INQUIRY_SCAN state at least every TGAP(102) and Non-interlaced Inquiry scan is used.

In all cases the Bluetooth device shall enter the INQUIRY_SCAN state at least once in TGAP(102) and scan for the GIAC for at least TGAP(101).

When either a SCO or eSCO link is in operation, it is recommended to use interlaced scan to significantly decrease the discoverability time.

A device in general discoverable mode shall not respond to a LIAC inquiry.

4.1.3.3. Term on UI-level

Bluetooth device is ‘discoverable’ or in ‘discoverable mode’.

4.2. Connectability modes

With respect to paging, a Bluetooth device shall be either in non-connectable mode or connectable mode. Paging is defined in [Vol 2] Part B, Section 8.3.

When a Bluetooth device is in non-connectable mode it does not respond to paging. When a Bluetooth device is in connectable mode it responds to paging.

The speed of connections is dependent on the configuration of the page scan interval and page scan type of the Bluetooth device. The Host is able to configure these parameters based on trade-offs between power consumption, bandwidth and the desired speed of connection.

4.2.1. Non-connectable mode
4.2.1.1. Definition

When a Bluetooth device is in non-connectable mode it shall never enter the PAGE_SCAN state.

4.2.1.2. Term on UI-level

Bluetooth device is ‘non-connectable’ or in ‘non-connectable mode’.

4.2.2. Connectable mode
4.2.2.1. Definition

When a Bluetooth device is in connectable mode it shall periodically enter the PAGE_SCAN state. The device performs page scan using the Bluetooth Device Address, BD_ADDR. Connection speed is a trade-off between power consumption / available bandwidth and speed. The Bluetooth Host is able to make these trade-offs using the Page Scan interval, Page Scan window, and Interlaced Scan parameters.

R0 page scanning should be used when connection speeds are critically important and when the paging device has a very good estimate of the Bluetooth clock. Under these conditions it is possible for paging to complete within two times the page scan window. Because the page scan interval is equal to the page scan window it is not possible for any other traffic to go over the Bluetooth link when using R0 page scanning. In R0 page scanning it is not possible to use interlaced scan. R0 page scanning is the highest power consumption mode of operation.

When connection times are critical but the other device either does not have an estimate of the Bluetooth clock or when the estimate is possibly out of date, it is better to use R1 page scanning with a very short page scan interval, TGAP(106), and Interlaced scan. This configuration is also useful to achieve nearly the same connection speeds as R0 page scanning but using less power and leaving bandwidth available for other connections. Under these circumstances it is possible for paging to complete within TGAP(106). In this case the Bluetooth device shall page scan for at least TGAP(101).

When connection times are important but not critical enough to sacrifice significant bandwidth and/or power consumption it is recommended to use either TGAP(107) or TGAP(108) for the scanning interval. Using Interlaced scan will reduce the connection time by half but may use twice the power consumption. Under these circumstances it is possible for paging to complete within one or two times the page scanning interval depending on whether Interlaced Scan is used. In this case the Bluetooth device shall page scan for at least TGAP(101).

In all cases the Bluetooth device shall enter the PAGE_SCAN state at least once in TGAP(102) and scan for at least TGAP(101).

The page scan interval, page scan window size, and scan type for the six scenarios are described in Table 4.2:

Scenario

Page Scan Interval

Page Scan Window

Scan Type

R0 (1.28 s)

TGAP(107)

TGAP(107)

Normal scan

Fast R1 (100 ms)

TGAP(106)

TGAP(101)

Interlaced scan

Medium R1 (1.28 s)

TGAP(107)

TGAP(101)

Interlaced scan

Slow R1 (1.28 s)

TGAP(107)

TGAP(101)

Normal scan

Fast R2 (2.56 s)

TGAP(108)

TGAP(101)

Interlaced scan

Slow R2 (2.56 s)

TGAP(108)

TGAP(101)

Normal scan

Table 4.2: Page scan parameters for connection speed scenarios


When either a SCO or eSCO link is in operation, it is recommended to use interlaced scan to significantly decrease the connection time.

4.2.2.2. Term on UI-level

Bluetooth device is ‘connectable’ or in ‘connectable mode’.

4.3. Bondable modes

With respect to bonding, a Bluetooth device shall be either in non-bondable mode or in bondable mode. In bondable mode the Bluetooth device accepts bonding initiated by the remote device, and in non-bondable mode it does not.

4.3.1. Non-bondable mode
4.3.1.1. Definition

When a Bluetooth device is in non-bondable mode it shall not accept a pairing request that results in bonding. Devices in non-bondable mode may accept connections that do not request or require bonding.

A device in non-bondable mode shall respond to a received LMP_IN_RAND with LMP_NOT_ACCEPTED with the reason pairing not allowed.

When both devices support Secure Simple Pairing and the local device is in non-bondable mode, the local Host shall respond to an IO capability request where the Authentication_Requirements parameter requests dedicated bonding or general bonding with a negative response.

4.3.1.2. Term on UI-level

Bluetooth device is ‘non-bondable’ or in ‘non-bondable mode’ or “does not accept bonding”.

4.3.2. Bondable mode
4.3.2.1. Definition

When a Bluetooth device is in bondable mode, and Secure Simple Pairing is not supported by either the local or remote device, the local device shall respond to a received LMP_IN_RAND with LMP_ACCEPTED (or with LMP_IN_RAND if it has a fixed PIN).

When both devices support Secure Simple Pairing, the local Host shall respond to a user confirmation request with a positive response.

4.3.2.2. Term on UI-level

Bluetooth device is ‘bondable’ or in ‘bondable mode’ or “accepts bonding”.

4.4. Synchronizability modes

A Bluetooth device shall be either in non-synchronizable mode or synchronizable mode. The synchronization train procedure is defined in [Vol 2] Part B, Section 2.7.2.

When a Bluetooth device is in synchronizable mode, it transmits timing and frequency information for its active Connectionless Peripheral Broadcast packets. When a Bluetooth device is non-synchronizable, timing and frequency information is not transmitted.

The Host is able to configure the Synchronization Train interval based on trade-offs between bandwidth, potential interference to other devices, power consumption, and the desired time for a Peripheral to receive a synchronization train packet.

4.4.1. Non-synchronizable mode
4.4.1.1. Definition

When a Bluetooth device is in non-synchronizable mode it shall never enter the Synchronization Train substate.

4.4.1.2. Term on UI-level

Bluetooth device is ‘non-synchronizable’ or in ‘non-synchronizable mode’.

4.4.2. Synchronizable mode
4.4.2.1. Definition

When a Bluetooth device is in synchronizable mode, it shall enter the Synchronization Train substate using a synchronization train interval of TGAP(Sync_Train_Interval).

After being made synchronizable, the Bluetooth device shall be synchronizable for at least TGAP(Sync_Train_Duration).

4.4.2.2. Term on UI-level

Bluetooth device is 'synchronizable' or in 'synchronizable mode'.

5. Security aspects – BR/EDR physical transport

Procedure

Ref.

Support

Authentication

5.1

M

Security mode 1

5.2.1.1

E

Security mode 2

5.2.1.2

C.1

Security mode 3

5.2.1.3

E

Security mode 4

5.2.2

M

C.1:

Security mode 2 may only be used for backwards compatibility when the remote device does not support Secure Simple Pairing.

Table 5.1: Conformance requirements related to the generic authentication procedure and the security modes defined in this section


5.1. Authentication
5.1.1. Purpose

The generic authentication procedure describes how the LMP-authentication and LMP-pairing procedures are used when authentication is initiated by one Bluetooth device towards another, depending on if a link key exists or not and if pairing is allowed or not.

5.1.2. Term on UI level

‘Bluetooth authentication’.

5.1.3. Procedure

Figure 5.1 defines the generic authentication procedure.

Definition of the generic authentication procedure
Figure 5.1: Definition of the generic authentication procedure


5.1.4. Conditions

The local device shall initiate authentication after link establishment. The remote device may initiate security during or after link establishment.

5.2. Security modes

The flow chart in Figure 5.2, including the steps in Figure 5.3, Figure 5.4, and Figure 5.5, specifies the overall channel establishment procedures. The following subsections give more details of these procedures.

Channel establishment with security
Figure 5.2: Channel establishment with security


A device may support two security modes simultaneously: security mode 2 for backwards compatibility with remote devices that do not support Secure Simple Pairing and security mode 4 for devices that support Secure Simple Pairing.

5.2.1. Legacy security modes

Legacy security modes apply to those devices with a Controller or a Host that does not support SSP.

5.2.1.1. Security mode 1 (non-secure)

When a remote Bluetooth device is in security mode 1 it will never initiate any security procedure (i.e., it will never send LMP_AU_RAND, LMP_IN_RAND or LMP_ENCRYPTION_MODE_REQ).

5.2.1.2. Security mode 2 (service level enforced security)

When a remote Bluetooth device is in security mode 2 it will not initiate any security procedure before a channel establishment request (L2CAP_CONNECTION_REQ) has been received or a channel establishment procedure has been initiated by itself. Whether a security procedure is initiated or not depends on the security requirements of the requested channel or service.

A Bluetooth device in security mode 2 should classify the security requirements of its services using at least the following attributes:

  • Authorization required

  • Authentication required

  • Encryption required

Note

Note: Security mode 1 can be considered (at least from a remote device point of view) as a special case of security mode 2 where no service has registered any security requirements.

5.2.1.3. Security mode 3 (link level enforced security)

When a remote Bluetooth device is in security mode 3 it will initiate security procedures before it sends LMP_SETUP_COMPLETE.

A Bluetooth device in security mode 3 may reject the Host connection request (respond with LMP_NOT_ACCEPTED to the LMP_HOST_CONNECTION_REQ) based on settings in the Host (e.g., only communication with pre-paired devices allowed).

Security mode 3 with a legacy remote device
Figure 5.3: Security mode 3 with a legacy remote device


5.2.2. Security mode 4 (service level enforced security)

A Bluetooth device in security mode 4 shall classify the security requirements of its services using at least the following attributes (in order of decreasing security):

  • Authenticated link key required

  • Unauthenticated link key required

  • Security optional; limited to specific services (see Section 5.2.2.8).

When both devices support Secure Simple Pairing, GAP shall require at least an unauthenticated link key and enabling encryption for all connections except those allowed to have security level 0 (see Section 5.2.2.8). A profile or protocol may define services that require more security (e.g., an authenticated link key) or no security (although unencrypted connections are only allowed when connecting to a service allowed to have security level 0). To allow an unauthenticated link key to be created during the Secure Simple Pairing procedure, the Authentication_Requirements parameter may be set to one of the MITM Protection Not Required options.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing mode prior to entering Connectable Mode or establishing a link.

A Bluetooth device in security mode 4 shall respond to authentication requests during link establishment when the remote device is in security mode 3 for backwards compatibility reasons.

A Bluetooth device in security mode 4 enforces its security requirements before it attempts to access services offered by a remote device and before it grants access to services it offers to remote devices. Service access may occur via L2CAP channels or via channels established by protocols above L2CAP such as RFCOMM.

For services transmitting unicast data over the connectionless L2CAP channel, the transmitting device shall enforce its security requirements prior to sending data. There is no mechanism for a device receiving data via the L2CAP connectionless channel to prevent unencrypted data from being received. Hence, Section 5.2.2.1 addresses unicast connectionless data transmission together with devices initiating connection-oriented channels while Section 5.2.2.2 covers only devices responding to requests for connection-oriented channel establishment but does not cover unicast connectionless data reception.

A device may be in a Secure Connections Only mode. When in Secure Connections Only mode, all services (except those allowed to have Security Mode 4, Level 0) available on the BR/EDR physical transport require Security Mode 4, Level 4. The device shall reject both new outgoing and incoming service level connections when the service requires Security Mode 4, Level 4 and either the physical transport does not support Secure Connections or unauthenticated pairing is being requested.

A device operating with a physical transport operating in Secure Connections Only mode may disconnect the ACL connection using error code 0x05 (Authentication Failure) when the physical transport that does not support Secure Connections, tries to access a service that requires Security Mode 4, Level 4.

Note

Note: A device may operate several physical transports simultaneously - in this case all physical transports are required to enable Secure Connections Only Mode simultaneously.

5.2.2.1. Security for access to remote service (initiating side)

When the responding device does not support Secure Simple Pairing, it may disconnect the link while the initiating device is requesting the PIN to be entered by the user. This may occur due to the lack of an L2CAP channel being present for longer than an implementation-specific amount of time (e.g., a few seconds). When this occurs, the initiating device shall allow the user to complete entering the PIN and shall then re-page the remote device and restart the pairing procedure (see [Vol 2] Part C, Section 4.2.2) using the PIN entered.

5.2.2.1.1. Pairing required for access to remote service

When a Bluetooth device in security mode 4 initiates access to a remote service via a connection-oriented L2CAP channel, the service requires security, and a sufficient link-key is not available, the local device shall perform pairing procedures and enable encryption before sending a channel establishment request (an L2CAP connection request or a higher-layer channel establishment request such as that of RFCOMM).

When a Bluetooth device in security mode 4 transmits data to a remote service via the unicast connectionless L2CAP channel and a sufficient link-key is not available, the local device shall perform pairing procedures and enable encryption before transmitting unicast data on the connectionless L2CAP channel.

See Section 5.2.2.8 for details on determining whether or not a link key is sufficient.

If pairing does not succeed, the local device shall not send a channel establishment request. The local device may re-try pairing up to three (3) times. If pairing fails three consecutive times, the local device shall disconnect the ACL link with error code 0x05 - Authentication Failure.

If the link key generated is not at least as good as the expected or required type, the local device shall fail the establishment and may disconnect the ACL link with error code 0x05 - Authentication Failure.

5.2.2.1.2. Authentication required for access to remote service

When a Bluetooth device in security mode 4 initiates access to a remote service via a connection-oriented L2CAP channel and a sufficient link key is available for the remote device, it shall authenticate the remote device and enable encryption before sending a channel establishment request (an L2CAP connection request or a higher layer-channel establishment request such as that of RFCOMM).

When a Bluetooth device in security mode 4 transmits unicast data to a remote service via the connectionless L2CAP channel and security is required for the application and a sufficient link-key is available then the local device shall authenticate the remote device and enable encryption before transmitting unicast data on the L2CAP connectionless channel.

See Section 5.2.2.8 for details on determining whether or not a link key is sufficient.

If authentication is required by the service but does not succeed, or if a sufficient link-key is not available, then the local device shall not enable encryption. If encryption is not enabled or if enabling encryption does not result in the correct encryption type (i.e. AES-CCM or E0), the local device shall not send a channel establishment request and shall not send any unicast data via the L2CAP connectionless channel for that application. The Host may then notify the user and offer to perform pairing.

Channel establishment using security mode 4 for initiating side
Figure 5.4: Channel establishment using security mode 4 for initiating side


5.2.2.1.3. Cross-transport key generation and distribution

After encryption is enabled and both devices support cross-transport key generation, the Central of the BR/EDR transport may perform LE key generation and distribution ([Vol 3] Part H, Section 2.3.5.7). The Peripheral shall not perform LE key generation and distribution.

If a role switch gets performed after enabling encryption but before the LE keys can be generated and distributed, the new Central may perform LE key generation and distribution once the role switch has completed. The new Peripheral shall not perform LE key generation and distribution once the role switch has completed.

5.2.2.2. Security for access to local service by remote device (responding side)

When a remote device attempts to access a service offered by a Bluetooth device that is in security mode 4 and the service requires security, a sufficient link key exists, and authentication has not been performed, the local device shall authenticate the remote device and enable encryption after the channel establishment request is received but before a channel establishment confirmation (L2CAP connection response with result code of 0x0000 or a higher-level channel establishment confirmation such as that of RFCOMM) is sent.

When L2CAP is the channel establishment protocol being used for the requested service, an L2CAP connection response signaling packet shall be sent by the responding device containing a pending result code following receipt of an L2CAP connection request and prior to initiating security procedures which can result in prompting the local user for input (e.g., pairing using a PIN or Secure Simple Pairing using either the Passkey entry or Numerical Comparison association models). This will stop the L2CAP RTX timer on the remote device (which may be as short as 1 second) and will invoke the ERTX timer on the remote device, which is a minimum duration of 60 seconds.

See [Vol 3] Part A, Section 6.2 for additional information on L2CAP RTX and ERTX timers. See also [Vol 3] Part A, Section 4.3 and [Vol 3] Part A, Section 4.26 for additional information on the L2CAP connection response signaling packets and the defined result codes.

Higher layer channel establishment protocols should be designed to restrict timeouts to be 30 seconds or longer to allow for user input, or provide mechanisms to dynamically extend timeouts when user input may be required.

If authentication or pairing fails when a remote device is attempting to access a local service, the local device shall send a negative response to the channel establishment request (L2CAP connection request or application-specific channel establishment request) indicating a security issue if possible. If the channel establishment protocol is L2CAP, then the result code in the L2CAP connection response shall be set to indicate that the connection was refused due to security reasons. If an L2CAP_CONNECTION_RSP is being sent, then the result code shall be set to 0x0003 (connection refused - security block). If an L2CAP_CREDIT_BASED_CONNECTION_RSP is being sent, then the result code shall be set to 0x0005 (All connections refused - insufficient authentication), 0x0006 (All connections refused - insufficient authorization), 0x0007 (All connections refused - encryption key size too short), or 0x0008 (All connections refused - insufficient encryption).

If the remote device has indicated support for Secure Simple Pairing, a channel establishment request is received for a service other than SDP, and encryption has not yet been enabled, then the local device shall disconnect the ACL link with error code 0x05 - Authentication Failure.

5.2.2.2.1. Pairing required for access to local service by remote device

When a remote device attempts to access a service offered by a Bluetooth device that is in security mode 4 and pairing is required due to the link key being absent or insufficient, the local device shall perform pairing procedures and enable encryption after the channel establishment request is received and before a channel establishment confirmation (L2CAP connection response with result code of 0x0000 or a higher-level channel establishment response such as that of RFCOMM) is sent.

See Section 5.2.2.6 for details on determining whether or not a link key is sufficient.

If pairing does not succeed, then the local device shall not send a channel establishment confirmation. The local device may retry pairing up to three (3) times. If pairing fails three consecutive times, then the local device shall disconnect the ACL link with error code 0x05 - Authentication Failure.

If the link-key generated is not at least as good as the expected or required type or if enabling encryption does not result in the correct encryption type (i.e. AES-CCM or E0), then the local device shall fail the channel establishment and may disconnect the ACL link with error code 0x05 - Authentication Failure.

5.2.2.2.2. Authentication required for access to local service by remote device

See Section 5.2.2.6 for details on determining whether or not a link key is sufficient.

If authentication does not succeed, then the local device shall not send a channel establishment confirmation. The Host may at this point notify the user and offer to perform pairing.

A Bluetooth device in security mode 4 shall respond to authentication and pairing requests during link establishment when the remote device is in security mode 3 for backwards compatibility reasons. However, authentication of the remote device shall be performed after the receipt of the channel establishment request is received, and before the channel establishment response is sent.

Channel establishment using security mode 4 for the responding side
Figure 5.5: Channel establishment using security mode 4 for the responding side


5.2.2.2.3. Cross-transport key generation and distribution

After encryption is enabled and both devices support cross-transport key generation, the Central of the BR/EDR transport may perform LE key generation and distribution ([Vol 3] Part H, Section 2.3.5.7). The Peripheral shall not perform LE key generation and distribution.

If a role switch gets performed after enabling encryption but before the LE keys can be generated and distributed, the new Central may perform LE key generation and distribution once the role switch has completed. The new Peripheral shall not perform LE key generation and distribution once the role switch has completed.

5.2.2.3. Secure Simple Pairing after authentication failure

When both devices support Secure Simple Pairing all non-SDP connections are encrypted regardless of whether security was required or whether the devices are bonded or not. The initial connection between the two devices will result in a link key through Secure Simple Pairing. Depending on whether or not bonding was performed and the security policy of the initiating device, the link key may be stored. When the link key is stored, subsequent connections to the same device will use authentication but this may fail if the remote device has deleted the link key. Table 5.2 defines what shall be done depending on the type of the link key and whether bonding was performed or not.

Link Key Type

Devices Bonded?

Action to take when Authentication Fails

Combination

No

Depends on security policy of the device:

  • Option 1: Automatically initiate pairing

  • Option 2: Notify user and ask if pairing is ok

Option 2 is recommended.

Combination

Yes

Notify user of security failure

Unauthenticated

No

Depends on security policy of the device:

  • Option 1: Automatically initiate secure simple pairing

  • Option 2: Notify user and ask if secure simple pairing is ok.

Option 1 is recommended.

Unauthenticated

Yes

Notify user of security failure

Authenticated

No

Depends on security policy of the device:

  • Option 1: Automatically initiate secure simple pairing

  • Option 2: Notify user and ask if secure simple pairing is ok

Option 2 is recommended.

Authenticated

Yes

Notify user of security failure

Table 5.2: Secure Simple Pairing after authentication failure


Non-bonded authenticated or unauthenticated link keys may be considered disposable by either device and may be deleted at any time.

5.2.2.4. IO capabilities

Once a connection is established, if the Host determines that security is necessary and both devices support Secure Simple Pairing, the devices perform an IO capability exchange. The purpose of the IO capability exchange is to determine the authentication algorithm used in the Authentication stage 1 phase of Secure Simple Pairing.

The input and output capabilities are described in Table 5.3:

Capability

Description

No input

Device does not have the ability to indicate 'yes' or 'no'

Yes / No

Device has at least two buttons that are mapped easily to 'yes' and 'no' or the device has a mechanism whereby the user can indicate either 'yes' or 'no' (see note below).

Keyboard

Device has a numeric keyboard that can input the numbers '0' to '9' and a confirmation. Device also has two buttons that can be easily mapped to 'yes' and 'no' or the device has a mechanism whereby the user can indicate either 'yes' or 'no' (see Note below).

Table 5.3: User input capabilities


Note

Note: 'yes' could be indicated by pressing a button within a certain time limit otherwise 'no' would be assumed.

Capability

Description

No output

Device does not have the ability to display or communicate a 6 digit decimal number

Numeric output

Device has the ability to display or communicate a 6 digit decimal number

Table 5.4: User output capabilities


5.2.2.5. Mapping of input / output capabilities to IO capability

The individual input and output capabilities are mapped to a single IO capability which is later used to determine which authentication algorithm will be used.

Local Output Capability

No Output

Numeric Output

Local Input

Capability

No input

NoInputNoOutput

DisplayOnly

Yes / No

NoInputNoOutput

DisplayYesNo

Keyboard

KeyboardOnly

DisplayYesNo

Table 5.5: IO capability mapping


When a device has OOB authentication information from the remote device, it will indicate it in the LMP_IO_CAPABILITY_RES PDU. When either device has OOB information, the OOB association model will be used.

The Host may allow the Link Manager to ignore the IO capabilities and use the Numeric Comparison protocol with automatic accept by setting the Authentication_Requirements parameter to one of the MITM Protection Not Required options.

5.2.2.6. IO and OOB capability mapping to authentication stage 1 method

Determining which association model to use in Authentication stage 1 is performed in three steps. First, the devices look at the OOB Authentication Data Present parameter received in the remote IO capabilities. If either device has received OOB authentication data then the OOB association model is used. The event of receiving the OOB information is indicated by a device to its peer in the IO Capability Exchange step of Secure Simple Pairing.

Device A

Has not received remote OOB authentication data

Has received remote OOB authentication data

Device B

Has not received remote OOB authentication data

Use the IO capability mapping table

Use OOB association with

ra = 0

rb from OOB

Has received remote OOB authentication data

Use OOB association with

ra from OOB

rb = 0

Use OOB association with

ra from OOB

rb from OOB

Table 5.6: IO and OOB capability mapping


Second, if neither device has received OOB authentication data and if both devices have set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices).

Finally, if neither device has received OOB authentication data and if one or both devices have set the Authentication_Requirements parameter to one of the MITM Protection Required options, the IO and OOB capabilities are mapped to the authentication stage 1 method as defined in Table 5.7. A Host that has set the Authentication_Requirements parameter to one of the MITM Protection Required options shall verify that the resulting Link Key is an Authenticated Combination Key (see [Vol 4] Part E, Section 7.7.24). Table 5.7 also lists whether the combination key results in an authenticated or unauthenticated link key.

Device A (Initiator)

Display Only

DisplayYesNo

KeyboardOnly

NoInputNoOutput

Device B (Responder)

DisplayOnly

Numeric Comparison with automatic confirmation on both devices.

Numeric Comparison with automatic confirmation on device B only.

Passkey Entry: Responder Display, Initiator Input.

Numeric Comparison with automatic confirmation on both devices.

Unauthenticated

Unauthenticated

Authenticated

Unauthenticated

DisplayYesNo

Numeric Comparison with automatic confirmation on device A only.

Numeric Comparison: Both Display, Both Confirm.

Passkey Entry: Responder Display, Initiator Input.

Numeric Comparison with automatic confirmation on device A only and Yes/No confirmation whether to pair on device B. Device B does not show the confirmation value.

Unauthenticated

Authenticated

Authenticated

Unauthenticated

Keyboard Only

Passkey Entry: Initiator Display, Responder Input.

Passkey Entry: Initiator Display, Responder Input.

Passkey Entry: Initiator and Responder Input.

Numeric Comparison with automatic confirmation on both devices.

Authenticated

Authenticated

Authenticated

Unauthenticated

NoInputNoOutput

Numeric Comparison with automatic confirmation on both devices.

Numeric Comparison with automatic confirmation on device B only and Yes/No confirmation on whether to pair on device A. Device A does not show the confirmation value.

Numeric Comparison with automatic confirmation on both devices.

Numeric

Comparison

with automatic confirmation on both devices.

Unauthenticated

Unauthenticated

Unauthenticated

Unauthenticated

Table 5.7: IO capability mapping to authentication stage 1


Note

Note: The "DisplayOnly" IO capability only provides unidirectional authentication.

5.2.2.7. Out of Band (OOB)

An out of band mechanism may also be used to communicate discovery information as well as other information related to the pairing process.

The contents of the OOB data block are:

Mandatory contents:

  • Length (2 bytes)

  • BD_ADDR (6 bytes)

Optional contents:

  • Class of Device (3 bytes)

  • Secure Simple Pairing Hash C (16 bytes)

  • Secure Simple Pairing Randomizer R (16 bytes)

  • Local name (variable length)

  • Other information

The length field includes all bytes in the OOB data block including the length field itself. The BD_ADDR will be a fixed field in the beginning of the OOB data block. Following the BD_ADDR will be zero or more EIR tag fields containing optional contents. The EIR tag format will be used for the optional contents. See Figure 5.6.

OOB data block format
Figure 5.6: OOB data block format


If Secure Simple Pairing fails when one or both devices have OOB Authentication Data present, both devices shall discard the OOB Authentication Data and the device that originally initiated authentication shall re-initiate authentication. Although the user may get involved in authentication as defined by the IO capabilities of the two devices, falling back to the in-band association model will prevent deadlock conditions when one or both devices has stale OOB Authentication Data.

There is a MIME type defined for use with the OOB data format. The MIME type can be found from the following link: http://www.iana.org/assignments/media-types/application/vnd.bluetooth.ep.oob

5.2.2.8. Security database

A Bluetooth device in security mode 4 shall classify and enforce the security requirements of its services using the following levels attributes (in order of decreasing security) for use when pairing with remote devices supporting Secure Simple Pairing:

  • Level 4, for services with the following attributes:

    Authentication of the remote device required

    MITM protection required

    128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not allowed; encryption key not shortened)

    User interaction acceptable

  • Level 3, for services with the following attributes:

    Authentication of the remote device required

    MITM protection required

    Encryption required

    At least 56-bit equivalent strength for encryption key should be used

    User interaction acceptable

  • Level 2, for services with the following attributes:

    Authentication of the remote device required

    MITM protection not required

    Encryption required

    At least 56-bit equivalent strength for encryption key should be used

  • Level 1, for services with the following attributes:

    Authentication of the remote device required when encryption is enabled

    MITM protection not required

    At least 56-bit equivalent strength for encryption key when encryption is enabled should be used

    Minimal user interaction desired

  • Level 0: Service requires the following:

    Authentication of the remote device not required

    MITM protection not required

    No encryption required

    No user interaction required

    Security Mode 4 Level 0 shall only be used for:

    1. L2CAP fixed signaling channels with CIDs 0x0001, 0x0003, and 0x003F

    2. SDP

    3. broadcast data sent on the connectionless L2CAP channel (CID 0x0002)

    4. services with the combinations of Service Class UUIDs and L2CAP traffic types listed in Section 1 of [5].

The security level required for each service offered should be stored in a security database that is accessed to determine the type of link key and the encryption key size that is required for access to the respective service. The security level required for service data transmitted on an L2CAP connection-oriented channel may differ from the security level required for service data transmitted on another L2CAP connection-oriented channel or on the connectionless L2CAP channel. Table 5.8 shows the type of link key required for each security level for both remote devices that support Secure Simple Pairing and for those that do not.

Security Level Required for Service

Link Key type required for remote devices that support SSP

Link Key type required for remote devices that do not support SSP

Comments

Level 4

  • Authentication of the remote device required

  • MITM protection required

  • Encryption required

  • User interaction acceptable

Authenticated

(P-256 based Secure Simple Pairing and Secure Authentication)

NA

Highest Security

Only possible when both devices support Secure Connections

Level 3

  • Authentication of the remote device required

  • MITM protection required

  • Encryption required

  • User interaction acceptable

Authenticated

Combination

(16 digit PIN recommended)

High Security

Level 2

  • Authentication of the remote device required

  • MITM protection not necessary

  • Encryption desired

Unauthenticated

Combination

Medium Security

Level 1

  • Authentication of the remote device required when encryption is enabled

  • MITM protection not necessary

  • Encryption not necessary1

  • Minimal user interaction desired

Unauthenticated

None

Low Security

Level 0

  • Authentication of the remote device not required

  • MITM protection not necessary

  • Encryption not necessary

  • No user interaction desired

None

None

Permitted only for SDP and service data sent via either L2CAP fixed signaling channels or the L2CAP connectionless channel to PSMs that correspond to service class UUIDs which are allowed to utilize Level 0.

1Though encryption is not necessary for the service for Level 1, the specification mandates the use of encryption for all services other than SDP when the remote device supports SSP.

Table 5.8: Security level mapping to link key requirements


An authenticated link key is a link key where either the numeric comparison, out-of-band, or passkey entry Secure Simple Pairing association models were used. An authenticated link key has protection against MITM attacks. To ensure that an authenticated link key is created during the Secure Simple Pairing procedure, the Authentication_Requirements parameter should be set to one of the MITM Protection Required options.

An unauthenticated link key is a link key where the “Just Works” Secure Simple Pairing association model was used (see [Vol 1] Part A, Section 5.2.4). An unauthenticated link key does not have protection against MITM attacks. To allow an unauthenticated link key to be created during the Secure Simple Pairing procedure, the Authentication_Requirements parameter may be set to one of the MITM Protection Not Required options.

When both devices support Secure Simple Pairing and at least one device does not support Secure Connections, the strength of the link key is 96 effective bits. When both devices support Secure Connections, the strength of the link key is 128 effective bits. Secure Connections does not change the protection against MITM attacks.

A combination link key is a link key where BR/EDR Legacy Pairing was used to generate the link-key (see [Vol 2] Part C, Section 4.2.2.4).

When both devices support Secure Simple Pairing, GAP shall require at least an unauthenticated link key and enable encryption for service traffic sent or received via connection-oriented L2CAP channels. A profile or protocol may define services that require more security (for example, an authenticated link key) or no security in the case of SDP or service traffic sent via the L2CAP connectionless channel for services that do not require security.

When the device is in Bondable Mode, it shall enable Secure Simple Pairing mode prior to entering Connectable Mode or establishing a link.

A Bluetooth device in security mode 4 shall respond to authentication and pairing requests during link establishment when the remote device is in security mode 3 for backwards compatibility reasons. See Section 5.2.1.3 for more information.

The remote Controller's and remote Host's support for Secure Simple Pairing shall be determined by the Link Manager Secure Simple Pairing (Host Support) feature bit.

A previously generated link key is considered “sufficient” if the link key type is of the type required for the service, or of a higher strength. Authenticated link keys are considered higher strength than Unauthenticated or Combination keys. Unauthenticated link keys are considered higher strength than Combination keys.

A device shall enforce an encryption key with at least 128-bit equivalent strength for all services that require Security Mode 4, Level 4. For all other services that require encryption, a device should enforce an encryption key with at least 56-bit equivalent strength, irrespective of whether the remote device supports Secure Simple Pairing.

After encryption has been enabled, the Host should check the encryption key size using either the HCI_Read_Encryption_Key_Size command (see [Vol 4] Part E, Section 7.5.7) or a vendor-specific method.

6. Idle mode procedures – BR/EDR physical transport

The requirements for devices initiating the inquiry and discovery procedures (device A) are specified in Table 6.1. The requirements on the behavior of the responding device (device B) are specified in Table 4.1.

Procedure

Ref.

Support

General inquiry

6.1

C.1

Limited inquiry

6.2

C.1

Name discovery

6.3

O

Device discovery

6.4

O

Bonding

6.5

O

C.1:

If initiation of bonding is supported, support for at least one inquiry procedure is mandatory, otherwise optional.

Note: Support for LMP-pairing is mandatory (see [Vol 2] Part C, Section 4.2.2).

Table 6.1: Requirements for initiating inquiry and discovery procedures


6.1. General Inquiry
6.1.1. Purpose

The purpose of the general inquiry procedure is to provide the initiator with the Bluetooth Device Address, clock, Class of Device, and extended inquiry response information of devices in either general discoverable mode or limited discoverable mode.

The general inquiry procedure should be used for general purpose discovery, i.e. to discover all discoverable devices regardless of whether they are in general discoverable mode or limited discoverable mode. A device which discovers devices using the general inquiry procedure and presents them to users in some fashion should distinguish devices in the limited discoverable mode from those in the general discoverable mode, e.g., by sorting them to the top of a list of discovered devices or highlighting them in some way.

Note

Note: The rationale for distinguishing the devices in limited discoverable mode to the end user is that devices typically enter limited discoverable mode only after explicit action by the end user, indicating that the user’s immediate goal is to discover and interact with that specific device.

6.1.2. Term on UI level

‘Bluetooth Device Inquiry’.

6.1.3. Description

Figure 6.1 specifies the procedure.

General inquiry, where B is a device in non-discoverable mode, B´ is a device in limited discoverable mode and B” is a device in general discoverable mode. (Note: All discoverable devices are discovered using general inquiry, independent of which discoverable mode they are in.)
Figure 6.1: General inquiry, where B is a device in non-discoverable mode, B´ is a device in limited discoverable mode and B” is a device in general discoverable mode. (Note: All discoverable devices are discovered using general inquiry, independent of which discoverable mode they are in.)


6.1.4. Conditions

When general inquiry is initiated by a Bluetooth device, the INQUIRY state shall last TGAP(100) or longer, unless the inquirer collects enough responses and determines to abort the INQUIRY state earlier. The Bluetooth device shall perform inquiry using the GIAC.

In order for Device A to receive inquiry responses, the remote devices in range have to be made discoverable (limited or general).

6.2. Limited Inquiry
6.2.1. Purpose

The purpose of the limited inquiry procedure is to provide the initiator with the Bluetooth Device Address, clock, Class of Device, and extended inquiry response information of limited discoverable devices. The latter devices are devices that are in range with regard to the initiator, and set to scan for inquiry messages with the Limited Inquiry Access Code.

The limited inquiry procedure should only be used when it is known that the devices to be discovered are using limited discoverable mode. The general inquiry procedure (see Section 6.1) should be used for general purpose discovery when it is desired to discover all devices regardless of whether they are using limited discoverable mode or general discoverable mode.

6.2.2. Term on UI level

’Bluetooth Device Inquiry’.

6.2.3. Description

Figure 6.2 specifies the procedure.

Limited inquiry where B is a device in non-discoverable mode, B’ is a device in limited discoverable mode and B” is a device in general discoverable mode. (Note: Only limited discoverable devices can be discovered using limited inquiry.)
Figure 6.2: Limited inquiry where B is a device in non-discoverable mode, B’ is a device in limited discoverable mode and B” is a device in general discoverable mode. (Note: Only limited discoverable devices can be discovered using limited inquiry.)


6.2.4. Conditions

When limited inquiry is initiated by a Bluetooth device, the INQUIRY state shall last TGAP(100) or longer, unless the inquirer collects enough responses and determines to abort the INQUIRY state earlier. The Bluetooth device shall perform inquiry using the LIAC.

In order for Device A to receive inquiry responses, the remote devices in range has to be made limited discoverable.

6.3. Name Discovery
6.3.1. Purpose

The purpose of name discovery is to provide the initiator with the Bluetooth Device Name of connectable devices (i.e., devices in range that will respond to paging).

6.3.2. Term on UI level

’Bluetooth Device Name Discovery’

6.3.3. Description
6.3.3.1. Name Request

Name request is the procedure for retrieving the Bluetooth Device Name from a connectable Bluetooth device. It is not necessary to perform the full link establishment procedure (see Section 7.1) in order to just to get the name of another device. Figure 6.3 specifies the procedure.

Name Request procedure
Figure 6.3: Name Request procedure


6.3.3.2. Name Discovery

Name discovery is the procedure for retrieving the Bluetooth Device Name from connectable Bluetooth devices by performing name request towards known devices (i.e., Bluetooth devices for which the Bluetooth Device Addresses are available). Figure 6.4 specifies the procedure.

Name discovery procedure
Figure 6.4: Name discovery procedure


6.3.4. Conditions

In the name request procedure, the initiator will use the Device Access Code of the remote device as retrieved immediately beforehand – normally through an inquiry procedure.

6.4. Device Discovery

This section only applies to BR/EDR-only and BR/EDR/LE implementations.

6.4.1. Purpose

The purpose of device discovery is to provide the initiator with the Bluetooth Device Address, clock, Class of Device, Bluetooth Device Name, and extended inquiry response information of discoverable devices.

6.4.2. Term on UI level

’Bluetooth Device Discovery’

6.4.3. Description

During the Device Discovery procedure, first an inquiry (either general or limited) is performed, and then name discovery is done towards some or all of the devices that responded to the inquiry. If the initiator of the device discovery receives a complete local name or a shortened local name that is considered long enough, via an extended inquiry response from a remote device, the initiator should not do a separate name discovery for that device.

Device Discovery procedure
Figure 6.5: Device Discovery procedure


6.4.4. Conditions

Conditions for both inquiry (general or limited) and name discovery must be fulfilled (i.e., devices discovered during device discovery must be both discoverable and connectable).

6.5. Bonding
6.5.1. Purpose

The purpose of bonding is to create a relation between two Bluetooth devices based on a common link key (a bond). The link key is created and exchanged (pairing) during the bonding procedure and is expected to be stored by both Bluetooth devices, to be used for future authentication. In addition to pairing, the bonding procedure can involve higher-layer initialization procedures.

6.5.2. Term on UI level

’Bluetooth Bonding’

6.5.3. Description

Two forms of bonding are described in the following sections: General Bonding and Dedicated Bonding.

6.5.3.1. General Bonding

General Bonding refers to the process of performing bonding during connection setup or channel establishment procedures as a precursor to accessing a service. Figure 6.6 specifies General Bonding.

When the devices that are performing General Bonding both support Secure Simple Pairing, the Authentication_Requirements parameter should be set to MITM Protection Not Required – General Bonding unless the security policy of an available local service requires MITM Protection in which case the Authentication_Requirements parameter shall be set to MITM Protection Required – General Bonding. 'No bonding' is used when the device is performing a Secure Simple Pairing procedure, but does not intend to retain the link key after the physical link is disconnected.

General Bonding procedure
Figure 6.6: General Bonding procedure


6.5.3.2. Dedicated Bonding

Dedicated Bonding refers to a procedure wherein one device connects to another only for the purpose of pairing without accessing a particular service. Figure 6.7 specifies Dedicated Bonding. The main difference with dedicated bonding, as compared to a pairing done during link or channel establishment, is that for bonding it is the paging device (A) that initiates the authentication.

When the devices that are performing Dedicated Bonding both support Secure Simple Pairing, the Authentication_Requirements parameter should be set to MITM Protection Not Required – Dedicated Bonding unless the security policy of an available local service requires MITM Protection in which case the Authentication Required parameter shall be set to MITM Protection Required – Dedicated Bonding. 'No bonding' is used when the device is performing a Secure Simple Pairing procedure, but does not intend to retain the link key after the physical link is disconnected.

As an exception to the normal process, device B shall also accept pairing before the exchange of LMP_SETUP_COMPLETE PDUs (this can only happen if device A conforms to a lower version of the specification).

Dedicated Bonding procedure
Figure 6.7: Dedicated Bonding procedure


6.5.4. Conditions

Before bonding can be initiated, the initiating device (A) must know the Device Access Code of the device to pair with. This is normally done by first performing device discovery. A Bluetooth Device that can initiate bonding (A) should use limited inquiry, and a Bluetooth Device that accepts bonding (B) should support the limited discoverable mode.

Bonding is in principle the same as link establishment with the conditions:

  • The paged device (B) shall be set into bondable mode. The paging device (A) is assumed to allow pairing since it has initiated the bonding procedure.

  • The paging device (the initiator of the bonding procedure, A) shall initiate authentication.

  • Before initiating the authentication part of the bonding procedure, the paging device should delete any link key corresponding to a previous bonding with the paged device.

7. Establishment procedures – BR/EDR physical transport

Procedure

Ref.

Support in A

Support in B

Link Establishment

7.1

M

M

Channel Establishment

7.2

O

M

Connection Establishment

7.3

O

O

Synchronization Establishment

7.5

O

O

Table 7.1: Establishment procedures


The establishment procedures defined here do not include any discovery part. Before establishment procedures are initiated, the information provided during device discovery (in the FHS packet or the extended inquiry response packet of the inquiry response or in the response to a name request or in the synchronization train packet) must be available in the initiating device.

This information is:

  • The Bluetooth Device Address (BD_ADDR) from which the Device Access Code is generated

  • The system clock of the remote device

Additional information provided during device discovery that may be useful for making the decision to initiate an establishment procedure is:

  • The Class of Device

  • The Device name

  • The supported Service Classes.

7.1. Link Establishment
7.1.1. Purpose

The purpose of the Link Establishment procedure is to establish a logical transport (of ACL type) between two Bluetooth devices using procedures from the Baseband Specification and Link Manager Protocol.

7.1.2. Term on UI level

‘Bluetooth link establishment’

7.1.3. Description

In this subsection, the paging device (A) is in security mode 3. During link establishment, the paging device cannot distinguish if the paged device (B) is in security mode 1, 2 or 4.

7.1.3.1. B in security mode 1, 2, or 4

Figure 7.1 specifies the procedure.

Link Establishment procedure when the paging device (A) is in security mode 3 and the paged device (B) is in security mode 1, 2, or 4
Figure 7.1: Link Establishment procedure when the paging device (A) is in security mode 3 and the paged device (B) is in security mode 1, 2, or 4


7.1.3.2. B in security mode 3

Figure 7.2 specifies the procedure.

Link Establishment procedure when both the paging device (A) and the paged device (B) are in security mode 3
Figure 7.2: Link Establishment procedure when both the paging device (A) and the paged device (B) are in security mode 3


7.1.4. Conditions

The paging procedure shall be according to [Vol 2] Part B, Section 8.3 and the paging device should use the Device Access Code and page mode received through a previous inquiry. When paging is completed, a physical link between the two Bluetooth devices is established.

If role switching is needed it should be done as early as possible after the physical link is established. If the paging device does not accept the switch, the paged device has to consider whether to keep the physical link or not.

Both devices may perform link setup (using LMP procedures that require no interaction with the Host on the remote side). Optional LMP features can be used after having confirmed (using LMP_FEATURES_REQ) that the other device supports the feature.

When the paging device needs to go beyond the link setup phase, it issues a request to be connected to the Host of the remote device. If the paged device is in security mode 3, this is the trigger for initiating authentication.

The paging device shall send LMP_HOST_CONNECTION_REQ during link establishment (i.e., before channel establishment) and may initiate authentication only after having sent LMP_HOST_CONNECTION_REQ.

After an authentication has been performed, any of the devices can initiate encryption.

Further link configuration may take place after the LMP_HOST_CONNECTION_REQ. When both devices are satisfied, they send LMP_SETUP_COMPLETE.

Link establishment is completed when both devices have sent LMP_SETUP_­COMPLETE.

7.2. Channel Establishment
7.2.1. Purpose

The purpose of the Channel Establishment procedure is to establish a Bluetooth channel (L2CAP channel) between two Bluetooth devices as described in [Vol 3] Part A, Section 4.2.

7.2.2. Term on UI level

’Bluetooth channel establishment’

7.2.3. Description

In this subsection, the initiator (A) is in security mode 3. During channel establishment, the initiator cannot distinguish if the acceptor (B) is in security mode 1 or 3.

7.2.3.1. B in security mode 2 or 4

Figure 7.3 specifies the procedure.

Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 2 or 4
Figure 7.3: Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 2 or 4


7.2.3.2. B in security mode 1 or 3

Figure 7.4 specifies the procedure.

Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 1 or 3
Figure 7.4: Channel Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 1 or 3


7.2.4. Conditions

Channel establishment starts after link establishment is completed when the initiator sends a channel establishment request (L2CAP_CONNECTION_­REQ).

Depending on security mode, security procedures may take place after the channel establishment has been initiated.

Channel establishment is completed when the acceptor responds to the channel establishment request (with a positive L2CAP_CONNECTION_­RSP).

7.3. Connection Establishment
7.3.1. Purpose

The purpose of the Connection Establishment procedure is to establish a connection between applications on two Bluetooth devices.

7.3.2. Term on UI level

’Bluetooth connection establishment’

7.3.3. Description

In this subsection, the initiator (A) is in security mode 3. During connection establishment, the initiator cannot distinguish if the acceptor (B) is in security mode 1 or 3. The connection establishment request and accept messages are defined by the application protocol.

7.3.3.1. B in security mode 2 or 4

Figure 7.5 specifies the procedure.

Connection Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 2 or 4
Figure 7.5: Connection Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 2 or 4


7.3.3.2. B in security mode 1 or 3

Figure 7.6 specifies the procedure.

Connection Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 1 or 3
Figure 7.6: Connection Establishment procedure when the initiator (A) is in security mode 3 and the acceptor (B) is in security mode 1 or 3


7.3.4. Conditions

Connection establishment starts after channel establishment is completed, when the initiator sends a connection establishment request. This request may be a TCS SETUP message [2] in the case of a Bluetooth telephony application Cordless Telephony Profile, or initialization of RFCOMM and establishment of DLC [1] in the case of a serial port-based application Serial Port Profile (although neither TCS or RFCOMM use the term ‘connection’ for this).

Connection establishment is completed when the acceptor accepts the connection establishment request.

7.4. Establishment of additional connection

When a Bluetooth device has established one connection with another Bluetooth device, it may be available for establishment of:

  • A second connection on the same channel, and/or

  • A second channel on the same logical link, and/or

  • A second physical link.

If the new establishment procedure is to be towards the same device, the security part of the establishment depends on the security modes used. If the new establishment procedure is to be towards a new remote device, the device should behave according to Active modes independent of the fact that it already has another physical link established (unless allowed co-incident radio and Baseband events have to be handled).

7.5. Synchronization Establishment
7.5.1. Purpose

The purpose of the Synchronization Establishment procedure is for a device to receive synchronization train packets using the procedures in [Vol 2] Part B, Section 2.7.3

7.5.2. Term on UI Level

’Bluetooth synchronization establishment’

7.5.3