[Erregend]

Does anyone have a list of the Bluetooth Profiles
that a phone must support in order to successfully
and completely integrate with the latest 3 Series?

Examples of Profiles are:
Headset (HSP)
Handsfree (HFP)
Dial-up networking (DUN)
Object Push (OPP)
Generic Access (GAP)
Serial Port (SPP)
Service Discovery Application (SDAP)

Sure would help in selecting a phone!

[tintivilus]

HFP

[Erregend]

Originally Posted by tintivilus

HFP

It must need more than that or just about every Bluetooth Phone around today would work.

I don't think HFP supports the phonebook, for example.

Am I wrong?

[SnEeKy4LiFe]

Not all phone will work.. if you have one of the new phones that just came out will not work with the car.. I just got a new phone and it doesnt work at all.... just check the bmw website and u will find phone that will work with your car..

[Technic]

Originally Posted by Erregend

It must need more than that or just about every Bluetooth Phone around today would work.

I don't think HFP supports the phonebook, for example.

Am I wrong?

Verizon used some type of HFP to push phonebook once (for the Motorola V710) instead of the OPP, but only for that phone to be compatible with the BMW TCU. So it is possible, but I doubt that it is now probable as OPP is less restricted as before.

The problem is not so much the profiles per se but how the profiles are implemented in each phone according to the carrier. As you stated, as all phones support HFP they all should be compatible, but that's simply not true. Each carrier tweak the profiles in a certain way which make compatibility with OEM systems at the best case, shaky.

For example, in my VW OEM Bluetooth I tested two Verizon phones: a RAZR V3c and a RAZR V3 Maxx. Both with the same profiles (HSP, HFP, DUN, OPP) except that the Maxx supports A2DP and the RAZR doesn't, both tranferred the phonebook, both worked fine for all the basic phone features. But the RAZR did not send the "Verizon" identification of the carrrier that can be seen in my screen, but the Maxx does.

Bluetooth is an standard in paper, but in reality it is not.

[tintivilus]

Originally Posted by Erregend

It must need more than that or just about every Bluetooth Phone around today would work.

I don't think HFP supports the phonebook, for example.

Am I wrong?

You're not wrong, but you're asking the wrong question. Last time I talked to anyone knowledgeable on the situation, phonebook was implemented completely outside any Bluetooth profile. HFP includes SPP (Serial Port Profile), and the TCU just uses this serial connection to communicate with the phone for phonebook sync using the 3GPP AT-Command set.

OPP doesn't help at all -- it's Object Push Profile. You could use it to manually send stuff to the car, but it's completely useless for pulling information from the phone without user interaction.

What would make all this go away is widespread implementation of PBAP (Phone Book Access Profile) but I've never seen it supported anywhere.

So anyway, the question you need to ask is "What AT Commands are needed for phonebook sync?", and I'm not sure anybody has a definitive list.

The net result is that phones on a platform that has been around as a phone for a while have fairly thorough support for the 3GPP Command Set. Smartphones started out with rudimentary support and have gradually been backfilling as customers have complained.

Originally Posted by Technic

Bluetooth is an standard in paper, but in reality it is not.

Actually, Bluetooth is an unusually clear standard with good compliance testing. The case here is the telematics OEMs wanted (understandably enough) phonebook support before the necessary Bluetooth profiles (specifically PBAP) were implemented, and/or wanted support with existing phones so they hacked together a system outside the Bluetooth standards & compliance certification regime. Now nobody's bothering to implement anything better because the existing setup works well enough -- there are too many existing car kits and phones to drop support for the old system, and nobody's going to spend money implementing a feature that they don't strictly need.

[Technic]

Originally Posted by tintivilus

Actually, Bluetooth is an unusually clear standard with good compliance testing. The case here is the telematics OEMs wanted (understandably enough) phonebook support before the necessary Bluetooth profiles (specifically PBAP) were implemented, and/or wanted support with existing phones so they hacked together a system outside the Bluetooth standards & compliance certification regime. Now nobody's bothering to implement anything better because the existing setup works well enough -- there are too many existing car kits and phones to drop support for the old system, and nobody's going to spend money implementing a feature that they don't strictly need.

Thanks, that's what I actually said... Bluetooth is an standard in paper, but between the carriers and OEM that standard is no more in reality.

[tintivilus]

Well, I think I agree with you in principle but disagree on semantics

There's a big marketing issue (and I think some intentional confusion) about what functionalities of a Bluetooth(tm)-branded device are covered by the Bluetooth (tm) standard and which are not. I can put the Bluetooth logo on a set of widgets that happen communicate via SPP because dammit SPP is part of Bluetooth, but that doesn't many any other SPP device is interchangeable with with mine.

From a communications perspective, Bluetooth profiles are a weird mix of various levels of communication stack. SPP, for example, is a pretty low-level communication standard, where DUN is just a list of AT-Commands an SPP device must support to be recognizable as a "modem".

In this particular case, the audio functionality of the carkit is completely 100% HFP, and rightfully Bluetooth (tm) Logo-tested. Phonebook sync, however, is only Bluetooth by virtue of happening to function over the Bluetooth SPP connection.

Now this isn't directly the fault of the Bluetooth SIG, but they do tend to move too slowly for the market when confronted with an issue they hadn't anticipated. This is an artifact of their design-by-committee approach to standards: by the time you've gotten representatives from dozens of companies to agree on a specification, the market doesn't care anymore since everyone's already done their own thing to ship by Christmas.

So the point I'm spending way too many words to make is that Phonebook isn't really a Bluetooth issue -- it's deceptive marketing that phonebook sync is a "Bluetooth" feature at all.

You can call me a Bluetooth.org apologist if you'd like, but it just bugs me that there is a perfectly good technical solution to this problem that just isn't being implemented.

What's probably going to end up happening, though, is that everyone will skip over PBAP and just start throwing SyncML over SPP or FTP. That'd be fine by me -- SyncML is designed for this sort of thing.

[Technic]

Originally Posted by tintivilus

Well, I think I agree with you in principle but disagree on semantics

There's a big marketing issue (and I think some intentional confusion) about what functionalities of a Bluetooth(tm)-branded device are covered by the Bluetooth (tm) standard and which are not. I can put the Bluetooth logo on a set of widgets that happen communicate via SPP because dammit SPP is part of Bluetooth, but that doesn't many any other SPP device is interchangeable with with mine.

From a communications perspective, Bluetooth profiles are a weird mix of various levels of communication stack. SPP, for example, is a pretty low-level communication standard, where DUN is just a list of AT-Commands an SPP device must support to be recognizable as a "modem".

In this particular case, the audio functionality of the carkit is completely 100% HFP, and rightfully Bluetooth (tm) Logo-tested. Phonebook sync, however, is only Bluetooth by virtue of happening to function over the Bluetooth SPP connection.

Now this isn't directly the fault of the Bluetooth SIG, but they do tend to move too slowly for the market when confronted with an issue they hadn't anticipated. This is an artifact of their design-by-committee approach to standards: by the time you've gotten representatives from dozens of companies to agree on a specification, the market doesn't care anymore since everyone's already done their own thing to ship by Christmas.

So the point I'm spending way too many words to make is that Phonebook isn't really a Bluetooth issue -- it's deceptive marketing that phonebook sync is a "Bluetooth" feature at all.

You can call me a Bluetooth.org apologist if you'd like, but it just bugs me that there is a perfectly good technical solution to this problem that just isn't being implemented.

What's probably going to end up happening, though, is that everyone will skip over PBAP and just start throwing SyncML over SPP or FTP. That'd be fine by me -- SyncML is designed for this sort of thing.

I do understand you point from the Bluetooth standard point of view. The issue that I have with that standard is deeper than just the Phonebook transfer... some phones simply don't pair at all/pair and drop to some OEM systems, although they have at least HFS.

USB is USB because it pretty works all the time, but this Bluetooth standard has been shaky since the get go. At least BMW has tried their best in making its OEM system to be compatible with the most quantity of phones possible, but damn... 13 versions of ULFs in 6 years to keep up?

At least my reality is that OEM and carriers are circunventing the BT standards for their own particular purposes, which then by definition simply defeat the purpose of the standard.