PBAP Data

- The reason PBAP is not typically considered part of the core Bluetooth stack is because it's an optional profile that provides a specific functionality - access to
phonebook data. Core Bluetooth stacks like BlueZ and Fluoride are primarily concerned with implementing the essential Bluetooth protocols and providing a
framework for general-purpose Bluetooth communication. PBAP, on the other hand, is an additional layer built on top of these core protocols to enable features such
as hands-free calling, caller ID display, and voice dialing.
- Phone Book Access Profile (PBAP) has dependencies on other Bluetooth profiles. PBAP relies on the Generic Object Exchange Profile (GOEP), the Serial Port Profile
(SPP), and the Generic Access Profile (GAP) for various functionalities. These dependencies allow PBAP to access phonebook data, establish communication channels,
and manage device discovery and connections effectively.
- Features available with the Latest PBAP profile along with the tradition phonebook sharing characteristic:
1. Added support for GOEP 2.0 (OBEX over L2CAP and Single Response Mode):
○ Traditional Bluetooth Communication:
▪ Without GOEP 2.0, the communication process might involve establishing a new Bluetooth connection for each contact being tran sferred.
▪ For each connection setup:
 The devices need to negotiate connection parameters, such as encryption settings and data transfer rates.
 Handshakes and acknowledgment messages are exchanged between the smartphone and the infotainment system, adding to the
communication overhead.
 After transferring each contact, the connection is torn down, requiring additional setup if more contacts need to be transfer red.
▪ This process results in significant overhead due to the repeated setup and teardown of connections, leading to longer transfe r times and reduced
efficiency.
○ GOEP 2.0-Enabled Communication:
○ With GOEP 2.0, the communication process is streamlined, reducing overhead and speeding up the transfer process.
○ The smartphone initiates a single Bluetooth connection with the car's infotainment system.
○ Within this single connection session:
○ Multiple contact entries can be transferred consecutively without the need for repeated connection setups.
○ GOEP 2.0's Single Response Mode allows the infotainment system to handle multiple transfer requests within the same connectio n, eliminating
the need for redundant handshakes and acknowledgments.
○ As a result, the transfer process becomes more efficient:
○ Communication overhead is minimized, as setup and teardown procedures are only required once for the entire transfer session.
○ The transfer speed is increased, as data can be transmitted continuously within the established connection without interrupti ons.
○ Overall, the contact information is transferred more quickly and seamlessly compared to the traditional Bluetooth communicati on approach.
In summary, GOEP 2.0 reduces overhead and speeds up the transfer process by optimizing the protocol stack, minimizing connection setup procedures, and enabling
efficient data transmission within a single connection session. This leads to a smoother and more efficient Bluetooth communication experience, especially when
transferring large datasets such as contact information.

1. Introduced Folder Version Counters:

• Example: Suppose you have a smartphone and a Bluetooth headset. After adding new contacts or modifying existing ones on your smartphone, you want to sync
the changes with your Bluetooth headset. The Folder Version Counters help in this synchronization process by indicating if any changes have occurred since the
last sync, ensuring that only the updated information is transferred.
2. Added vCard Selecting functionality:
• Example: Imagine you want to transfer only a specific group of contacts, such as your work contacts, from your smartphone to your car's Bluetooth system. With
vCard Selecting functionality, you can choose to transfer only the vCards associated with your work contacts, rather than transferring your entire contact list.
3. Enhanced Missed Calls feature, introducing a new counter for combined call history and reset command:
• Example: Let's say you have missed calls from both your personal and work contacts. The enhanced Missed Calls feature keeps track of these missed calls
separately. Additionally, if you want to reset the missed calls counter, perhaps after reviewing your call history, you can use the reset command to clear the
counter
4. Included support for Unique Caller Identifier (UCI):
• Example: Consider a scenario where you have two contacts with the same name in your phonebook. With UCI support, even if their names are identical, each
contact has a unique identifier associated with them. This helps your device accurately identify which contact is calling based on their unique identifiers, reducing
confusion.
5. Implemented Contact Unique Identifiers (UID) for cross-referencing between folders:
• Example: Suppose you have the same contact saved in both your "Work" and "Personal" folders. With Contact Unique Identifiers (UIDs), even though it's the
same contact, each instance has a unique identifier. This prevents duplication issues and ensures that updates made to one instance of the contact are reflected
across all folders.
6. Added support for Contact Image Default Format, enabling standardized handling of contact images:
• Example: When sharing contact information between different devices, such as a smartphone and a smartwatch, ensuring compatibility of contact images can be
challenging due to different image formats. With support for Contact Image Default Format, devices can use a standardized format for storing and displaying
contact images, ensuring seamless integration across devices.

------------------------------------------------------------------------------------------------------------------------------------------

Profile Stack

New Section 2 Page 1

 Example: Suppose you have a smartphone with PBAP support and a visual display (VD) with PBAP capability. When you want to view your phonebook contacts on the
VD screen, the following interactions occur:
1. The visual display (VD) acts as the PBAP client, while your smartphone acts as the PBAP server.
2. The VD sends a Service Discovery Protocol (SDP) request to discover available PBAP services on your smartphone.
3. Once the PBAP service is discovered, the VD initiates an OBEX connection (PBAP session) with your smartphone using the PBAP Target UUID.
4. The PBAP server on your smartphone responds to the OBEX connection request, and the PBAP session is established.
5. The VD then requests phonebook data from your smartphone, and the PBAP server responds by transmitting the requested data over the OBEX connection.
6. The PBAP client (VD) receives the phonebook data and displays it on the screen, allowing you to browse through contacts, viewdetails, etc.
This example illustrates how the Bluetooth protocol stack and PBAP components enable the sharing of phonebook data between a smartphone and a visual display
(VD).

Profile Fundamentals:

Bonding is essential for establishing a secure connection between the Phone Book Client Equipment and the Phone Book Server Equipment. Both devices must support
specific functionalities such as Inquiry and Inquiry Scan Mode to enable the bonding process. Once bonded, the devices can securely exchange phone book data and
utilize each other's services.

Application Layer
• Phone Book Repositories:
• Phone book repositories refer to the locations where phone book objects are stored. Examples include the local memory of a GSM mobile phone and the SIM
card inserted into the phone. Multiple repositories may exist, each containing different sets of phone book objects.
• Phone Book Objects:
• There are seven types of phone book objects defined within PBAP:
○ Main Phone Book (pb): Contains the user phone book of the current repository. It typically stores the contact list either in the phone's memory or on the
SIM card.
○ Incoming Calls History (ich): Stores a list of the most recently received calls.
○ Outgoing Calls History (och): Stores a list of the most recently made calls.
○ Missed Calls History (mch): Stores a list of the most recently missed calls.
○ Combined Calls History (cch): Represents the combination of ich, och, and mch.
○ Speed-Dial (spd): Stores a list of speed dial entries on the Phone Book Server Equipment (PSE).
○ Favorite Contacts (fav): Stores a list of favorite contacts on the PSE.

File Representation: In the file representation, all phone book entries are stored within a single file. When transferring the phone book to the car audio system, the
entire contact list is encapsulated within this single file.
File Content:
Name:JohnSmith,Number:123-456-7890
Name:AliceJohnson,Number:987-654-3210
Name:BobBrown,Number:555-123-4567

Folder Representation: In the folder representation, each phone book entry is represented as an individual file within a virtual folder. When transferring the phone
book to the car audio system, each contact is stored as a separate file within this folder.
Folder Structure:

Phone Book Folder

|-- John_Smith.vcf
|-- Alice_Johnson.vcf
|-- Bob_Brown.vcf

Each .vcf file represents a single phone book entry and contains information such as the contact's name and phone number.
Explanation:
• In the file representation, all phone book entries are contained within a single file, making it easy to transfer and processthe entire phone book at once.
• In the folder representation, each phone book entry is represented as an individual file within a folder structure, providingmore granularity and flexibility in
accessing and managing individual contacts.
Usage:
• File Representation: Suitable for quick and straightforward transfer of the entire phone book to another device.
• Folder Representation: Useful when you need to selectively manage or manipulate individual contacts, such as deleting or updating specific entries.

Following table provides an overview of various properties defined in different versions of the vCard format (v. 2.1, v. 3.0, and v. 4.0), along with their descriptions and

New Section 2 Page 2

Following table provides an overview of various properties defined in different versions of the vCard format (v. 2.1, v. 3.0, and v. 4.0), along with their descriptions and
examples:

Property
Name presence Description Example
v. 2.1 v. 3.0 v. 4.0
ADR Optional Optional Optional A structured representation of the physical delivery address for the vCard object. ADR;TYPE=home:;;123 Main
St.;Springfield;IL;12345;USA
AGENT Optional Optional Undefined Information about another person who will act on behalf of the vCard object. AGENT:http://mi6.gov.uk/007
Typically this would be an area administrator, assistant, or secretary for the individual.
Can be either a URL or an embedded vCard.
ANNIVERSARY Undefined Undefined Optional Defines the person's anniversary. ANNIVERSARY:19901021
BDAY Optional Optional Optional Date of birth of the individual associated with the vCard. BDAY:19700310
BEGIN Required Required Required All vCards must start with this property. BEGIN:VCARD
CALADRURI Undefined Undefined Optional A URL to use for sending a scheduling request to the person's calendar. CALADRURI:http://example.c
om/calendar/jdoe
CALURI Undefined Undefined Optional A URL to the person's calendar. CALURI:http://example.com/c
alendar/jdoe
CATEGORIES Optional Optional Optional A list of "tags" that can be used to describe the object represented by this vCard. CATEGORIES:swimmer,biker
CLASS Undefined Optional Undefined Describes the sensitivity of the information in the vCard. CLASS:public
CLIENTPIDMAP Undefined Undefined Optional Used for synchronizing different revisions of the same vCard. CLIENTPIDMAP:1;urn:uuid:3
df403f4-5924-4bb7-
b077-3c711d9eb34b
EMAIL Optional Optional Optional The address for electronic mail communication with the vCard object. EMAIL:johndoe@hotmail.com
END Required Required Required All vCards must end with this property. END:VCARD
FBURL Undefined Undefined Optional Defines a URL that shows when the person is "free" or "busy" on their calendar. FBURL:http://example.com/fb
/jdoe
FN Optional Required Required The formatted name string associated with the vCard object. FN:Dr. John Doe
GENDER Undefined Undefined Optional Defines the person's gender. GENDER:F
GEO Optional Optional Optional Specifies a latitude and longitude. 2.1, 3.0:
GEO:39.95;-75.1667
4.0:
GEO:geo:39.95,-75.1667
IMPP Undefined Maybe Optional Defines an instant messenger handle. This property was introduced in a separate IMPP:aim:johndoe@aol.com
RFC when the latest vCard version was 3.0.
Therefore, 3.0 vCards might use this property without otherwise declaring it.
KEY Optional Optional Optional The public encryption key associated with the vCard object. It may point to an external 2.1:
URL, may be plain text, or may be embedded in the vCard as a Base64 encoded block KEY;PGP:http://example.co
of text. m/key.pgp
2.1:
KEY;PGP;ENCODING=BAS
E64:[base64-data]
3.0:
KEY;TYPE=PGP:http://exa
mple.com/key.pgp
3.0:
KEY;TYPE=PGP;ENCODIN
G=b:[base64-data]
4.0:
KEY;MEDIATYPE=applicati
on/pgp-
keys:http://example.com/ke
y.pgp
4.0:
KEY:data:application/pgp-
keys;base64,[base64-data]
KIND Undefined Undefined Optional Defines the type of entity that this vCard represents: 'application', 'individual', 'group', KIND:individual
'location' or 'organization'; 'x-*' values may be used for experimental purposes.[2][3]
LABEL Optional Optional Incorporat Represents the actual text that should be put on the mailing label when delivering a LABEL;TYPE=HOME:123
ed without physical package to the person/object associated with the vCard (related to the ADR Main St.\nSpringfield, IL
property). Not supported in version 4.0. Instead, this information is stored in the LABEL 12345\nUSA
parameter of the ADR property. Example: ADR;TYPE=home;LABEL="123 Main St
\nNew York, NY 12345":;;123 Main St;New York;NY;12345;USA
LANG Undefined Undefined Optional Defines a language that the person speaks. LANG:fr-CA
LOGO Optional Optional Optional An image or graphic of the logo of the organization that is associated with the individual 2.1:
to which the vCard belongs. It may point to an external URL or may be embedded in the LOGO;PNG:http://example.
vCard as a Base64 encoded block of text. com/logo.png
2.1:
LOGO;PNG;ENCODING=BA
SE64:[base64-data]
3.0:
LOGO;TYPE=PNG:http://ex
ample.com/logo.png
3.0:
LOGO;TYPE=PNG;ENCODI
NG=b:[base64-data]
4.0:
LOGO;MEDIATYPE=image/
png:http://example.com/log

New Section 2 Page 3

 png:http://example.com/log
o.png
4.0:
LOGO;ENCODING=BASE64
;TYPE=PNG:[base64-data]
MAILER Optional Optional Undefined Type of email program used. MAILER:Thunderbird
MEMBER Undefined Undefined Optional Defines a member that is part of the group that this vCard represents. Acceptable MEMBER:urn:uuid:03a0e51f-
values include:a "mailto:" URL containing an email address d1aa-4385-8a53-
a UID which references the member's own vCard e29025acd8af

The KIND property must be set to "group" in order to use this property.
N Required Required Optional A structured representation of the name of the person, place or thing associated with N:Doe;John;;Dr;
the vCard object. Structure recognizes, in order separated by semicolons: Family Name,
Given Name, Additional/Middle Names, Honorific Prefixes, and Honorific Suffixes[4]
NAME Undefined Optional Undefined Provides a textual representation of the SOURCE property.
NICKNAME Undefined Optional Optional One or more descriptive/familiar names for the object represented by this vCard. NICKNAME:Jon,Johnny
NOTE Optional Optional Optional Specifies supplemental information or a comment that is associated with the vCard. NOTE:I am proficient in
Tiger-Crane Style,\nand I am
more than proficient in the
exquisite art of the Samurai
sword.
ORG Optional Optional Optional The name and optionally the unit(s) of the organization associated with the vCard ORG:Google;GMail
object. This property is based on the X.520 Organization Name attribute and the X.520 Team;Spam Detection Squad
Organization Unit attribute.
PHOTO Optional Optional Optional An image or photograph of the individual associated with the vCard. It may point to an 2.1:
external URL or may be embedded in the vCard as a Base64 encoded block of text. PHOTO;JPEG:http://exampl
e.com/photo.jpg
2.1:
PHOTO;JPEG;ENCODING=
BASE64:[base64-data]
3.0:
PHOTO;TYPE=JPEG;VALU
E=URI:http://example.com/
photo.jpg
3.0:
PHOTO;TYPE=JPEG;ENCO
DING=b:[base64-data]
4.0:
PHOTO;MEDIATYPE=image
/jpeg:http://example.com/ph
oto.jpg
4.0:
PHOTO;ENCODING=BASE6
4;TYPE=JPEG:[base64-
data]
PRODID Undefined Optional Optional The identifier for the product that created the vCard object. PRODID:-//ONLINE
DIRECTORY//NONSGML
Version 1//EN
PROFILE Optional Optional Undefined States that the vCard is a vCard. PROFILE:VCARD
RELATED Undefined Undefined Optional Another entity that the person is related to. Acceptable values include:a "mailto:" URL RELATED;TYPE=friend:urn:u
containing an email address uid:03a0e51f-
a UID which references the person's own vCard d1aa-4385-8a53-
a text value used to specify textual information e29025acd8af
REV Optional Optional Optional A timestamp for the last time the vCard was updated. REV:20121201T134211Z
ROLE Optional Optional Optional The role, occupation, or business category of the vCard object within an organization. ROLE:Executive
SORT-STRING Undefined Optional Incorporat Defines a string that should be used when an application sorts this vCard in some way. SORT-STRING:Doe
ed without Not supported in version 4.0. Instead, this information is stored in the SORT-AS
parameter of the N and/or ORG properties.
SOUND Optional Optional Optional By default, if this property is not grouped with other properties it specifies the 2.1:
pronunciation of the FN property of the vCard object. It may point to an external URL or SOUND;OGG:http://exampl
may be embedded in the vCard as a Base64 encoded block of text. e.com/sound.ogg
2.1:
SOUND;OGG;ENCODING=
BASE64:[base64-data]
3.0:
SOUND;TYPE=OGG:http://e
xample.com/sound.ogg
3.0:
SOUND;TYPE=OGG;ENCO
DING=b:[base64-data]
4.0:
SOUND;MEDIATYPE=audio
/ogg:http://example.com/so
und.ogg
4.0:
SOUND:data:audio/ogg;bas
e64,[base64-data]
SOURCE Optional Optional Optional A URL that can be used to get the latest version of this vCard. SOURCE:http://johndoe.com/
vcard.vcf
TEL Optional Optional Optional The canonical number string for a telephone number for telephony communication with TEL;TYPE=cell:(123)
the vCard object. 555-5832
TITLE Optional Optional Optional Specifies the job title, functional position or function of the individual associated with the TITLE:V.P. Research and

New Section 2 Page 4

TITLE Optional Optional Optional Specifies the job title, functional position or function of the individual associated with the TITLE:V.P. Research and
vCard object within an organization. Development
TZ Optional Optional Optional The time zone of the vCard object. 2.1, 3.0: TZ:-0500
4.0: TZ:America/New_York
UID Optional Optional Optional Specifies a value that represents a persistent, globally unique identifier associated with UID:urn:uuid:da418720-3754-
the object. 4631-a169-db89a02b831b
URL Optional Optional Optional A URL pointing to a website that represents the person in some way. URL:http://www.johndoe.com
VERSION Required Required Required The version of the vCard specification. In version 4.0, this must come right after the VERSION:3.0
BEGIN property.
XML Undefined Undefined Optional Any XML data that is attached to the vCard. This is used if the vCard was encoded in XML:<b>Not an xCard XML
XML (xCard standard) and the XML document contained elements which are not part of element</b>
the xCard standard.

The "Call History extension" refers to an additional feature introduced in the vCard specification to accommodate call history information within vCard entries. This extension
utilizes the X-IRMC-CALL-DATETIME property, which extends the standard vCard format defined in the IrMC (Ir Mobile Communications) specification.
Here's a breakdown of how it works:
1. X-IRMC-CALL-DATETIME Property: This property is used to timestamp each call found in specific folders (och, ich, mch, and cch) within the vCard.
2. Property Parameters:
○ MISSED: Indicates a missed call.
○ RECEIVED: Indicates a received call.
○ DIALED: Indicates a dialed call.
3. Timestamp Format: The timestamp provided by X-IRMC-CALL-DATETIME is in local time, adjusted for the time zone and daylight saving time (DST). This ensures that
the displayed time aligns with the user's local time.
4. Usage Examples:
For vCard 2.1:

X-IRMC-CALL-DATETIME;MISSED:20050320T100000

For vCard 3.0:

X-IRMC-CALL-DATETIME;TYPE=MISSED:20050320T100000

These examples demonstrate how the X-IRMC-CALL-DATETIME property is used to indicate a missed call on March 20th, 2005, at 10:00 AM.
Overall, the Call History extension provides a standardized way to include call history information within vCard entries, enhancing compatibility and interoperability across
different systems and platforms.

PBAP Folder Structure

The organization and management of phone book information within the "telecom" and "SIM1/telecom" folders, typically found in mobile devices or SIM cards. Here's
an explanation with an example:
1. Location of Phone Book Information:
○ Local phone book information is stored under the "telecom" folder.
○ If the device contains a SIM card, SIM card phone book information is located under the "SIM1/telecom/" folder.
2. Unlimited Entries:
○ There is no limit to the number of entries a phone book can contain, allowing for comprehensive storage of contact informatio n.
3. Reserved Handle 0.vcf:
○ The handle "0.vcf" within the "pb" folder is reserved for the owner card.
○ This handle always exists and its associated vCard shall be returned when requested.
○ The "0.vcf" vCard should contain at least the mobile number of the PSE (Phone System Equipment), if known.
○ If the owner card is unknown, "0.vcf" can reference an empty vCard or a vCard containing the mobile number of the PSE.
4. Ascending Order by Handle Number:

New Section 2 Page 5

 4. Ascending Order by Handle Number:
○ The vCards located in the "pb" folder shall be arranged in ascending order by handle number.
○ When the vCard-listing object for "pb" is requested, the default order shall also be in ascending order by handle number.
5. Bulk Retrieval via vcf Files:
○ The vcf files directly under the "telecom" and/or "SIM1/telecom" folders contain all vCards of the corresponding phone book o bject.
○ These files can be used to retrieve the entire object in one operation, facilitating efficient data retrieval.

Default Contact Image Format for the vCard PHOTO Property

The requirements for the default contact image format when using the vCard PHOTO property in the context of the Phone Book Access Profile (PBAP). Here's an
explanation with an example:
1. Image Specifications:
○ The image pixel size must not exceed 300 pixels in width and 300 pixels in height.
○ The file size of the image must not exceed 50 kilobytes (50 kB).
2. Compression and Encoding:
○ Contact images must use JPEG compression.
○ The image data should be encoded in the vCard PHOTO property using base64 encoding.
3. Restrictions:
○ Other compression and encoding algorithms should not be used for the PHOTO property, ensuring compatibility and standardizati on.
Example: Suppose a contact named "John Doe" has an associated image for their vCard entry. The image file meets the specifications outlined above:
• Image File: "john_doe_photo.jpg"
○ Dimensions: 250 pixels wide, 200 pixels high
○ File Size: 40 kilobytes
When encoding this image data into the vCard PHOTO property, it would look something like this:

Example:
PHOTO;TYPE=JPEG;ENCODING=BASE64:/9j/4AAQSkZJRgABAQEASABIAAD/4QawRXhpZgAATU0AKgAAAAgAAQESAAMAAAABAAEAAAAAAAD/4QA5RX...

In this example:
• PHOTO indicates the PHOTO property.
• TYPE=JPEG specifies the image type as JPEG.
• ENCODING=BASE64 denotes that the image data is encoded in base64 format.
• /9j/4AAQSkZJRgABAQEASABIAAD/4QawRXhpZgAATU0AKgAAAAgAAQESAAMAAAABAAEAAAAAAAD/4QA5RX... represents the base64-encoded image data.

This encoded data can then be included in the vCard entry for "John Doe", ensuring that the image meets the specified criteria for compatibility and size limitations
within the PBAP environment.

Encoding in this context allows binary image data to be represented as text within a vCard entry, facilitating its inclusion and transmission within the constraints of the
PBAP environment.

-----------------------------------------------------
Phone Book Access Features

the support requirements for various features by both the Phone Book Client Equipment (PCE) and the Phone Book Server Equipment (PSE) in the context of the Phone
Book Access Profile (PBAP). Here's an explanation:
1. Download:
○ PCE (Client) Requirement (C1): At least one of the features listed in the table must be supported.
○ PSE (Server) Requirement (M): The PSE must support the Download feature.
2. Browsing:
○ Both PCE and PSE must support the Browsing feature, denoted by 'C1' and 'M' respectively.
3. Database Identifier:
○ PCE Requirement (C3): Mandatory if either 'Folder Version Counters' or 'X-BT-UID vCard Property' is supported.
○ PSE Requirement (M): The PSE must support the Database Identifier feature.
4. Folder Version Counters:
○ PCE Requirement (O): Optional.
○ PSE Requirement (M): The PSE must support Folder Version Counters.
5. vCard Selecting:
○ PCE Requirement (O): Optional.
○ PSE Requirement (M): The PSE must support vCard Selecting.
6. Enhanced Missed Calls:
○ PCE Requirement (O): Optional.
○ PSE Requirement (O): Optional.
7. X-BT-UCI vCard Property and X-BT-UID vCard Property:
○ Both properties are optional for both PCE and PSE, denoted by 'O' for each.
8. Referencing Contacts:
○ PCE Requirement (C2): Optional if 'X-BT-UID vCard Property' is supported, excluded otherwise.
○ PSE Requirement (C2): Optional if 'X-BT-UID vCard Property' is supported, excluded otherwise.
9. Contact Image Default Format:
○ PCE Requirement (X): Excluded.
○ PSE Requirement (M): The PSE must support the Contact Image Default Format.
In summary, this table specifies the level of support required for each feature by both the PCE and the PSE. It ensures interoperability between devices implementing
the PBAP standard.

1. Download:
▪ Example: If a smartphone (PCE) supports downloading the phone book via PBAP, it can retrieve contact information from a Bluetooth -enabled car's

New Section 2 Page 6

 ▪ Example: If a smartphone (PCE) supports downloading the phone book via PBAP, it can retrieve contact information from a Bluetooth -enabled car's
infotainment system (PSE) when connected. This allows the user to access their contacts through the car's interface.
2. Browsing:
▪ Example: A smartwatch (PCE) supports browsing through the phone book stored on a smartphone (PSE) via PBAP. The user can scroll thro ugh their contacts
on the smartwatch's display without needing to access the smartphone directly.
3. Database Identifier:
▪ Example: If a tablet (PCE) supports folder version counters or unique vCard identifiers, it can effectively manage and synchronize c ontact information with a
laptop (PSE) when connected via Bluetooth. This ensures that updates to the phone book are properly tracked and synced betwee n devices.
4. Folder Version Counters:
▪ Example: A Bluetooth-enabled printer (PSE) supports folder version counters. When a user prints a document containing contact information, the pri nter
ensures it has the latest version of the phone book to include up-to-date contact details.
5. vCard Selecting:
▪ Example: A digital photo frame (PSE) supports vCard selecting. When a user transfers photos from their smartphone (PCE) to the digit al photo frame via
Bluetooth, they can choose specific contacts' images to display alongside the photos.
6. Enhanced Missed Calls:
▪ Example: A smart speaker (PSE) supports enhanced missed calls. When a user asks the smart speaker to read out missed calls, it can p rovide additional
details such as the time and date of each missed call, retrieved from the phone book on a connected smartphone (PCE).
7. X-BT-UCI vCard Property and X-BT-UID vCard Property:
▪ Example: A smart TV (PSE) and a smartphone (PCE) both support these custom vCard properties. When the user mirrors their smartphone' s screen to the
smart TV, the TV displays caller information with unique caller identifiers and user contact identifiers associated with each incoming call.
8. Referencing Contacts:
▪ Example: A smart home hub (PSE) and a smart thermostat (PCE) both support referencing contacts. When the user sets up personalized t emperature
settings for different family members, the smart thermostat can reference the contacts stored on the smart home hub to adjust settings accordingly.
9. Contact Image Default Format:
▪ Example: A digital photo frame (PSE) supports the contact image default format. When a user transfers contacts from their smartphone (PCE) to the digital
photo frame via Bluetooth, the frame automatically resizes and displays contact images within the specified dimensions and fi le size limits.

========================================================================

Phone Book Access Profile Functions

The PullPhoneBook function with an example scenario:

Suppose you have a smartphone (PCE) and a car infotainment system (PSE) connected via Bluetooth. You want to retrieve the entire phone book from your
smartphone onto the car's display.
1. Request Initiation:
○ You initiate the request from the car's infotainment system (PSE) to pull the phone book data from your smartphone (PCE).
2. Request Formatting:
○ The car's PSE sends a GET request (Opcode: 0x03 or 0x83) to the smartphone's PCE.
○ The request specifies the type of data being requested as "x-bt/phonebook" and includes various application parameters such as PropertySelector, Format,
MaxListCount, ListStartOffset, etc.
○ If supported, it includes headers for Single Response Mode and Single Response Mode Param.
3. Transmission:
○ The request packet is transmitted over the Bluetooth connection from the car's PSE to the smartphone's PCE.
4. Processing on PCE:
○ The smartphone's PCE receives the request and processes it.
○ It identifies the requested phone book object and begins preparing the response.
5. Response Generation:
○ The smartphone's PCE retrieves the entire phone book data requested, including contacts' names, numbers, and other details.
○ It formats the phone book data according to the specified parameters, such as format type and maximum list count.
6. Response Transmission:
○ The smartphone's PCE sends the response packet containing the phone book data back to the car's PSE over the Bluetooth connec tion.
7. Reception and Display on VD:
○ The car's PSE receives the response packet and extracts the phone book data.
○ It then displays the phone book entries on the visual display (VD) of the car's infotainment system for the driver to access.
8. User Interaction:
○ The driver can now browse through the phone book entries on the car's display, view contact details, and make calls directly from the infotainment system.

In this example, the PullPhoneBook function facilitates the seamless transfer of phone book data from the smartphone to the car's infotainment system, enhancing
user convenience and accessibility while driving.

==========================================================
OBEX

OBEX stands for Object Exchange, and it is a communication protocol designed for the exchange of binary objects between devices. It's commonly used in Bluetooth file
transfer scenarios, such as transferring files between mobile phones, computers, and other devices.
Here's an overview of OBEX:
1. Purpose: OBEX facilitates the exchange of various types of data objects, including files, contact information, calendar entries, andmore, between devices.
2. Protocol: OBEX operates over various transport protocols, with Bluetooth being one of the most common. It typically runs over RFCOMM (Radio Frequency
Communication), a protocol used for serial port emulation over Bluetooth.
3. Characteristics:
○ Lightweight: OBEX is designed to be lightweight and efficient, making it suitable for resource -constrained devices like mobile phones and IoT devices.
○ Session-oriented: OBEX establishes a session between two devices for data exchange, allowing multiple operations to occur within the same session.
Header-based: Communication in OBEX is structured around headers, which contain metadata and control information about the data bein g transferred.

New Section 2 Page 7

 ○ Header-based: Communication in OBEX is structured around headers, which contain metadata and control information about the data bein g transferred.
○ Object-oriented: OBEX treats data as objects, which can be files, contacts, calendar entries, or any other type of binary data.
4. Operations: OBEX defines various operations for interacting with objects, including:
○ Connect: Establishes a session between two devices.
○ Disconnect: Ends the session.
○ Put: Sends an object from the client to the server.
○ Get: Retrieves an object from the server.
○ Delete: Deletes an object on the server.
5. Applications: OBEX is widely used in Bluetooth-enabled devices for tasks such as file transfer, synchronization of contacts and calendars, printing documents, and
more.

Overall, OBEX provides a standardized protocol for interoperable data exchange between devices over Bluetooth and other transport protocols, contributing to
seamless connectivity and data sharing in the digital ecosystem.

Let's walk through a simple example of using OBEX for file transfer between two Bluetooth-enabled devices, like two smartphones:
1. Device Initialization:
○ Two smartphones, Device A (sender) and Device B (receiver), are Bluetooth-enabled and have OBEX support.
2. Bluetooth Connection:
○ Device A initiates a Bluetooth connection with Device B.
3. OBEX Session Establishment:
○ Once the Bluetooth connection is established, Device A and Device B initiate an OBEX session. They negotiate parameters for t he session, such as
supported headers and features.
4. File Transfer Request (PUT Operation):
○ Device A wants to send a photo to Device B.
○ Device A initiates a PUT operation in OBEX, indicating that it wants to send an object (the photo) to Device B.
5. Header Exchange:
○ Devices exchange OBEX headers containing metadata about the file transfer, such as the file name, size, and format.
6. File Transfer:
○ Device A begins sending the photo data in chunks to Device B using the OBEX protocol.
7. Acknowledgment:
○ After receiving each chunk, Device B sends acknowledgment messages to confirm successful reception.
8. Completion and Disconnect:
○ Once the entire photo is transferred, Device A and Device B complete the OBEX session.
○ They disconnect the Bluetooth connection.
This is a simplified example, and in real-world scenarios, there could be additional negotiation steps, error handling, and support for different types of data objects
beyond files.

OBEX is versatile, and its use extends beyond file transfers. For instance, it is used in Bluetooth profiles like the Phone Book Access Profile (PBAP) for exchanging
contact information between devices. The key idea is that OBEX provides a standardized way for devices to communicate and exchange data, contributing to seamless
interoperability in the Bluetooth ecosystem.

How authorization/authentication challenge works in the PBAP ? how it is different from the traditional normal BT authorization like pin method etc.?

1. User Authentication:
○ Sarah starts her car and initiates the process to access her contacts on the infotainment system.
○ The infotainment system prompts Sarah to authenticate herself by entering her smartphone's passcode or providing biometric authentication (e.g., fingerprint or
face recognition) on her smartphone.
2. Challenge-Response Mechanism:
○ Once Sarah authenticates herself on her smartphone, the infotainment system sends a challenge to the smartphone to prove its identity.
○ The smartphone responds with cryptographic tokens or credentials, verifying its identity and authorization to access the phone book data.
3. Access Granted:
○ After successful authentication and verification, the infotainment system grants access to Sarah's phone book data.
○ Sarah can now browse and interact with her contacts on the car's display screen.

New Section 2 Page 8