1 INTRODUCTION

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 guarantee that links and channels always can be established between

Bluetooth devices, and that multi-profile operation is possible. 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 guarantee a satisfac-tory

user experience.

1.2 SYMBOLS AND CONVENTIONS

1.2.1 Requirement status symbols

In this document (especially in the profile requirements tables), the following

symbols are used:

‘M’ for mandatory to support (used for capabilities that shall be used in the

profile);

’O’ for optional to support (used for capabilities that can be used in the profile);

‘C’ for conditional support (used for capabilities that shall be used in case a cer-tain

other capability is supported);

‘X’ for excluded (used for capabilities that may be supported by the unit but

shall never be used in the profile);

’N/A’ for not applicable (in the given context it is impossible to use this

capability).

Some excluded capabilities are capabilities that, according to the relevant

Bluetooth specification, are mandatory. These are features that may degrade

operation of devices following this profile. Therefore, these features shall never

be activated while a unit is operating as a unit within this profile.

In this specification, the word shall is used for mandatory requirements, the

word should is used to express recommendations and the word may is used for

options.

 

 

1.2.2 Signalling diagram conventions

 

The following arrows are used in diagrams describing procedures

:

Figure 1.1: Arrows used in signalling diagrams

In the table above, 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-pro-cedure

where the initiating side is undefined (may be both A or B). Dashed

arrows denote optional steps. PROC4 indicates an optional sub-procedure ini-tiated

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, and MSG4 indicates a con-ditional

message from B to A.

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: ’T GAP (nnn)’.

 

 

 

                                        

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                                               MSG 1

 

 

                                               MSG 2

 

 

                                               MSG 3

 

                                              

                                               MSG 4

 

 

 

 

2 PROFILE OVERVIEW

2.1 PROFILE STACK

		Object Exchange Protocol (OBEX)
	Telephony Control Protocol (TCS)			RFCOMM		Service Discovery Protocol (SDP)

 

 

 

 

 

 

 

 

 

 

 

	Baseband [Link Controller (LC)]

 

 

 

Figure 2.1: Profile stack covered by this profile.

 

The main purpose of this profile is to describe the use of the lower layers of the

Bluetooth protocol stack (LC and LMP). To describe security related alterna-tives,

also higher layers (L2CAP, RFCOMM and OBEX) are included.

2.2 CONFIGURATIONS AND ROLES

For the descriptions in this profile of the roles that the two devices involved in a

Bluetooth communication can take, the generic notation of the A-party (the

paging device in case of link establishment, or initiator in case of another pro-cedure

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 the establish-ment

of the 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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 2.2: This profile covers procedures initiated by one device (A) towards another device

(B) that may or may not 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.3 USER REQUIREMENTS AND SCENARIOS

The Bluetooth user should in principle 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 applica-tion

but are from different manufacturers, the ability to connect them should not

be blocked just because manufacturers choose to call basic Bluetooth capabil-ities

by different names on the user interface level or implement basic proce-dures

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 inter-face

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 discoverable. 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. dedi-cated

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 mode that allows them to

accept connections and service requests.

2.5 CONFORMANCE

Bluetooth devices that do not conform to any other Bluetooth profile shall con-form

to this profile to ensure basic interoperability and co-existence.

Bluetooth devices that conform to another Bluetooth profile may use adapta-tions

of the generic procedures as specified by that other profile. They shall,

however, be compatible with devices compliant to this profile at least on the

level of the supported generic procedures.

If conformance to this profile is claimed, all capabilities indicated mandatory for

this profile shall be supported in the specified manner (process-mandatory).

This also applies for all optional and conditional capabilities for which support is

indicated. All mandatory capabilities, and optional and conditional capabilities

for which support is indicated, are subject to verification as part of the Blue-tooth

certification program.

 

3 USER INTERFACE ASPECTS

3.1 THE USER INTERFACE LEVEL

In the context of this 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 represen-tation

of Bluetooth terminology and parameters.

This profile specifies the generic terms that should be used on the user inter-face

level.

3.2 REPRESENTATION OF BLUETOOTH PARAMETERS

3.2.1 Bluetooth device address (BD_ADDR)

3.2.1.1 Definition

BD_ADDR is the unique address of a Bluetooth device as defined in [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 UI level, the term ’Bluetooth

Device Address’ should be used.

3.2.1.3 Representation

On BB level the BD_ADDR is represented as 48 bits [1].

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’.) At UI level, any number shall

have the MSB -> LSB (from left to right) ’natural’ ordering (e.g., the number ’16’

shall be shown as ’0x10’).

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

presents itself with. It is a character string returned in LMP_name_res as

response to a LMP_name_req.

3.2.2.2 Term on user interface level

When the Bluetooth device name is referred to on 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 maximum according to [2].

It shall be encodedaccording to UTF-8 (i.e. name entered on UI level may be

down to 82 characters outside the Unicode range 0x00-0x7F are used).

A device can not 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 PIN is used to authenticate two Bluetooth devices (that have not

previously exchanged link keys) to each other and create a trusted relationship

between them. The PIN is used in the pairing procedure (see Section 10.2) to

generate the initial link key that is used for further authentication.

The PIN may be entered on UI level but may also be stored in the device; e.g.

in the case of a device without sufficient MMI for entering and displaying digits.

3.2.3.2 Terms at user interface level

When the Bluetooth PIN is referred to on UI level, the term ’Bluetooth Passkey’

should be used.

3.2.3.3 Representation

The Bluetooth PIN has different representations on different levels. PINBB is

used on baseband level, and PINUI is used on user interface level.

PINBB is the PIN used by [1] for calculating the initialization key during the

pairing procedure. PINUI is the character representation of the PIN that is

entered on UI level. The transformation from PINUI to PINBB shall be accord-ing

to UTF-8 and decimal digits shall be within the Unicode range 0x00 - 0x7F.

According to [1], PINBB can be 128 bits (16 bytes). I.e. if a device supports

entry of characters outside the Unicode range 0x00 - 0x7F, the maximum num-ber

of characters in the PINUI may be less than 16.

Examples:

User-entered code	Corresponding PIN BB [0..length-1] (value as a sequence of octets in hexadecimal notation)
’0123’	length = 4, value = 0x30 0x31 0x32 0x33
’Ärlich’	length = 7, value = 0xC3 0x84 0x72 0x6C 0x69 0x63 0x68

 

All Bluetooth devices that support the bonding procedure and support PIN

handling on UI level shall support UI level handling of PINs consisting of deci-mal

digits. In addition, devices may support UI level handling of PINs consisting

of general characters.

If a device has a fixed PIN (i.e. PIN is stored in the device and cannot be

entered on UI level during pairing), the PIN shall be defined using decimal dig-its.

A device that is expected to pair with a remote device that has restricted UI

capabilities should ensure that the PIN can be entered on UI level as decimal

digits.

 

3.2.4 Class of Device

3.2.4.1 Definition

Class of device is a parameter received during the device discovery procedure,

indicating the type of device and which types of service that are supported.

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 Types and Bluetooth Service Types are defined in [11].

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 [11]. The UI-level representa-tion

of the information in the Class of device is implementation specific.

 

3.3 PAIRING

Two procedures are defined that make use of the pairing procedure defined on

LMP level (LMP-pairing, see Section 10.2). 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’.