[MSDN] 蓝牙配对、HFP、PBAP、A2DP、AVRCP和DUN的概括性介绍

Overview of Bluetooth Pairing

 

Bluetooth® is a short range wireless technology which enables wireless data transmission between two Bluetooth–enabled devices located nearby each other.

The Bluetooth stack is comprised of a layered architecture that facilitates data transport between Bluetooth-enabled devices. Each protocol is implemented by an architectural layer known as a profile. Each profile implements a different protocol and contributes to the ability to establish a link and facilitate data transport between devices that support the Bluetooth stack. Wireless networking between Bluetooth–enabled devices is achieved through a physical channel between each Bluetooth–enabled device, through which one or more logical channels are established. Using the logical channel, Bluetooth devices perform logical transport through the profile specific to the type of data being transmitted. Logical links established over the physical channel are managed by Logical Link Control and Adaptation Protocol (L2CAP).

For in depth discussion of Bluetooth architecture, obtain and read the Bluetooth v2.0 Specification.

Bluetooth–enabled devices, including the Windows Embedded CE powered device, host the Bluetooth stack along with the profiles required for the types of data communications that the Bluetooth–enabled device wants to conduct through a Bluetooth wireless connection.

Bluetooth Profiles

A Bluetooth profile defines the requirements necessary for one Bluetooth–enabled device to exchange data with another specific type of Bluetooth–enabled device.

Bluetooth technology defines a wide range of profiles that describe many different use cases. Windows Embedded CE supports the hands–free profile (HFP), which describes how a gateway device (mobile phone) can be used to place and receive calls for a hands–free device (Windows Embedded CE). The Advanced Audio Distribution Profile (A2DP) describes how stereo quality audio can be streamed from an audio source (for example, a media storage device) to an audio sink (for example, a wireless headset). A2DP defines the protocols and procedures that realize distribution of high-quality audio content in either mono or stereo through a Bluetooth wireless connection using Asynchronous connection-oriented (ACL) channels. ACL is a logical transport used to exchange asynchronous data and both Link Manager Protocol (LMP) and L2CAP control signaling.

Bluetooth Pairing

If one Bluetooth–enabled device is in discovery mode and discovers another Bluetooth–enabled device nearby, it can query for its services and choose to establish a Bluetooth link, or a 'pairing relationship', with the other Bluetooth–enabled device. Establishing a Bluetooth link with another Bluetooth–enabled device is also known as pairing.

The following illustration is a visual representation of Bluetooth wireless communication between two Bluetooth–enabled devices during service discovery:

 

[MSDN] Overview of Hands-Free Profile [Hands-Free Unit Role]

 

 

 

 

 

 

Windows Embedded NavReady supports the Bluetooth Hands-Free Profile (HFP). This enables a portable navigation device (PND) to be used together with a mobile phone to make voice calls.

With support for HFP, a PND becomes a hands-free device that can connect to and control a paired mobile phone in order to make and receive hands-free voice calls.

HFP Roles

The following roles are defined for Bluetooth-enabled devices that support HFP:

• Hands-Free Unit (HF) role: this role is for the device that controls input and receives output from the device in the Audio Gateway role; for example, a portable navigation device (PND).
• Audio Gateway (AG) role: this role is for the device that serves as a gateway of the audio, both for input and output; for example, a mobile phone.

A Windows Embedded NavReady powered device supports the Hands-Free Unit (HF) role only.

HFP Architecture Overview

To enable HFP support, Windows Embedded NavReady provides the HFP service in Windows Embedded CE, which manages Bluetooth HFP connections to a paired mobile phone. The HFP service also provides support for downloading a phone book by using Phone Book Access Profile (PBAP).

The following illustration shows the Bluetooth HFP architecture:

To enable making and receiving hands-free voice calls by using an Audio Gateway device, the Windows Embedded NavReady powered device pairs to a device, and then searches the Service Discovery Profile (SDP) record on that paired device to determine whether the device supports HFP. If it does support HFP, the Windows Embedded NavReady powered device assumes the Hands-Free Unit (HF) role in order to make and receive voice calls over a Bluetooth connection.

The HFP service communicates with the paired phone through the Bluetooth HFP connection to send telephony commands, to receive status updates, and to stream voice data from the paired phone to the hands-free device.

To use the capabilities offered by the HFP service, your custom hands-free phone application can call the HFP service APIs to perform telephony functions that are handled by Bluetooth HFP. For example, you can call specific HFP service APIs to respond to specific UI events, such as pressing a button in the UI to make a phone call or to download a phone book.

For more information about integrating HFP into a custom phone application, see Integrating the Hands-Free Profile (HFP) with a Phone Application.

HFP Capabilities

The HFP service in Windows Embedded NavReady provides the following capabilities to a custom phone application:

• Handles Bluetooth HFP port connected/disconnected status
• Makes a voice call by dialing a phone number
• Indicates when a voice call is connected or disconnected
• Notifies an application when a call is incoming (ring tone)
• Enables or disables in-band ringing
• Reports phone status (caller ID, signal strength, battery level, and so on)
• Notifies an application when caller ID is received
• Answers or rejects phone calls
• Receives notification of a call-waiting call with caller ID
• Puts the current call on hold and switches to the waiting call
• Switches back and forth between calls on hold and active calls
• Switches audio back to the mobile phone and returns audio back to the PND
• Retrieves the paired phone’s call list
• Reports status on the phone-book download (that uses PBAP)
• Receives electronic business cards (vCards) from a phone book by using OPP and OBEX
• Retrieves phone-book records
• Deletes phone-book records

HFP Support in an OS Design

To include support for HFP, add the Hands-Free Profile (HFP) (HF role) Catalog item (SYSGEN_BTH_HF) to your OS design.

To use HFP, the Windows Embedded NavReady powered device must support the ability to route Bluetooth SCO audio in the device hardware to the microphone and speakers. The Windows Embedded NavReady powered device must also support echo cancellation, which is required for HFP.

 

转自：https://docs.microsoft.com/en-us/previous-versions/windows/embedded/cc510823(v%3dmsdn.10)

 

Overview of Phone Book Access Profile (PBAP) (PCE Role)

 

 

Windows Embedded NavReady supports the Phone Book Access Profile (PBAP), which enables devices to exchange phone-book objects after a Bluetooth connection is established. Phone-book objects each represent information about a contact stored on a mobile phone.

With PBAP in Windows Embedded NavReady, you can enable users to download phone books from their mobile phones, which makes it possible to make hands-free phone calls to their contacts through the user interface on their Windows Embedded NavReady powered portable navigation devices (PNDs).

PBAP Roles

Two roles are defined for Bluetooth-enabled devices that support PBAP:

• Phone Book Server Equipment (PSE) role: this role is for the device that contains the source phone-book objects; for example, a mobile phone.
• Phone Book Client Equipment (PCE) role: this role is for the device that retrieves phone-book objects from the PSE device; for example, a portable navigation device (PND).

A Windows Embedded NavReady powered device supports the PCE role only.

PBAP Architecture Overview

With support for PBAP, a Windows Embedded NavReady powered device can create a pairing relationship with a mobile phone that also supports PBAP, download a phone book from that paired phone, and then use the contact entries in the phone book for making hands-free phone calls.

The following illustration shows the Bluetooth PBAP architecture:

To download a phone book from a mobile phone, the Windows Embedded CE powered portable navigation device (PND) pairs to a device, and then searches the Service Discovery Profile (SDP) record on that paired device to determine whether the device supports PBAP. If it does support PBAP, the PND assumes the Phone Book Client Equipment (PCE) role and uses elements from Infrared Mobile Communications (IrMC) protocol over Object Exchange Protocol (OBEX) to retrieve vCards (.vcf files) through a Bluetooth connection.

Each vCard contains information about contacts in a phone book. vCards can also contain information about incoming call history, outgoing call history, and missed call-history lists available on the mobile phone. The number of available entries in these call-history lists depends on both Windows Embedded NavReady and the capabilities of the device in the PSE role.

A mobile phone can store contacts and call histories on a Subscriber Identity Module (SIM) card, and also in memory, if both methods are supported by the paired phone. The Windows Embedded CE powered device can retrieve entries from both locations and merges them together, as soon as the data is retrieved from the paired phone.

Fore more information about how to use the HFP Service API to support phone book download and contact management in a custom phone application, see Phone Book Download and Contact Management.

PBAP Features

Phone Book Access Profile (PBAP) in Windows Embedded NavReady provides the following features:

• Automatic Download: this enables users to download the complete contents of a phone book automatically when the mobile phone is first connected to the PND. Automatic downloads can be performed by using PBAP, or by using SyncML or AT commands if PBAP is not supported.
• Manual Download: this enables users to choose to download, or sync, the complete contents of a phone book while the mobile phone is connected to the PND.
• vCard Version 2.1 Format: the vCard 2.1 specification defines a format for an electronic business card, or vCard.
• Support for Four Phone-Number Types: this provides support for the following phone-number types in a downloaded phone book: Work, Home, Cell, or Other.
• Local Phone-Book Storage: the Windows Embedded NavReady powered device can store the downloaded phone book locally, in persistent storage.
• Call-History Lists: Windows Embedded NavReady provides support for downloading a maximum of 25 outgoing phone calls, 25 incoming phone calls, and 25 missed phone calls from the call-history list on the phone.

Automatic Download Support

In Windows Embedded NavReady, only the phone-book download feature is supported, in which the complete phone book is downloaded or synced on the Windows Embedded NavReady powered device. Windows Embedded NavReady does not support selecting and sending individual contacts.

If the paired device does not support PBAP, Windows Embedded NavReady also supports other methods of downloading a phone book. If the paired phone includes PBAP in the SDP record but a download error occurs, the Windows Embedded NavReady powered device will try using SyncML. If SyncML fails or is not supported on the paired device, the Windows Embedded NavReady powered device tries using an AT command-based phone-book download.

If a PBAP download succeeds but contains zero entries, this might indicate that a download error occurred. As a result, the method described in the previous paragraph will be executed when the downloaded phone book has zero entries.

After three failed attempts of a PBAP download, the Windows Embedded NavReady powered device will put the phone on the block list and will not retry PBAP download.

 Note

Many Bluetooth-enabled phones will show a security confirmation dialog box the first time that the HFP service accesses PBAP on the phone.

Manual Download Support

With manual download, the user can send contacts to the PCE device any time that the user's phone is paired to it. The user can use manual download if the paired phone does not support automatic download, or if they simply want to send new contacts and append or update them in the downloaded phone book.

In order to use this feature, it must be supported by the UI on the Windows Embedded NavReady powered device.

vCard Version 2.0 Format

A vCard is a container for contact information in a format that complies with the vCard specification. This format enables various devices to exchange vCards. Windows Embedded NavReady supports vCard version 2.1.

A vCard is considered valid if all the following are true:

1. It contains at least one phone number with 2 or more digits.
2. Each line is exited only by using a carriage return and line feed (CRLF) character.
3. The character set used is either ASCII, UTF-8, or ISO 8859-1.
4. The vCard size does not exceed 400 KB.
5. If an encoding other than quoted-printable or 8-bit is not used.

Contacts Phone-Number Types

When it downloads the phone book or manually receives contacts from the paired phone, the Windows Embedded NavReady powered device will categorize the contacts as follows:

• For multiple phone numbers that belong to a contact, the phone-number type, also known as location, will be downloaded and stored as Work, Home, Cell, or Other.
• The Work phone-number type is applied for phone numbers with UI fields labeled "Work", "Business", or "Office".
• The Home phone-number type is applied for phone numbers with UI fields labeled "Home".
• The Cell phone-number type is applied for phone numbers with UI fields labeled "Cell" or "Mobile".

If the contact has multiple numbers labeled with the same phone-number type, both phone numbers will be stored with that phone-number type; for example, "Home (425) 555-1560, Home (425) 555-1834".

All categories that do not match Work, Home, or Cell are put into the Other phone-number type; for example, Fax, Pager, Work2, and so on.

Windows Embedded CE strips the leading spaces from contact entries that begin with space characters.

Call-History Lists

The Windows Embedded NavReady powered device downloads a call history that includes up to 25 outgoing phone calls, up to 25 incoming phone calls, and up to 25 missed phone calls from the call-history list on the phone. The call-history entries can be sorted by time stamp for each group (incoming phone calls, outgoing phone calls, and missed phone calls).

 Note

Some mobile phones support fewer entries for each list type.

The call history is downloaded as part of the automatic phone-book download routine.

A new call history can be downloaded every time that the phone connects, which will overwrite the stored copy of the list. The call history is also persisted across connection and reconnection cycles.

The call history will be updated as new phone-call activity occurs through the hands-free phone. However, the 25-number limit is the maximum for each category. If new phone calls are made that fill the call-history list, the least recently-made call is removed from the call-history list.

 Note

On phones that support SyncML or OBEX only, the call history reflects only those calls that occur while the phone is connected to the Windows Embedded CE powered device.

Call-history entries store up to 31 characters for the name or phone number.

To add a call to the call history, it must have a phone number associated with it. For example, a call dialed from a handset or received from an unknown number might not have a phone number associated with it.

Phone Book Local Storage

The Hands-Free Profile (HFP) service persists the downloaded phone books locally in RAM. Phone books can only be accessed while the Bluetooth-enabled phone associated with an individual phone book is paired to the portable navigation device (PND).

When a Windows Embedded NavReady powered portable navigation device (PND) user uses the PND UI to delete the phone book or delete a paired device, the phone book and call history that belongs to that device will also be deleted.

The local call-history list stores only phone calls that occur while a phone is connected to the PCE device. This call-history list is stored on the PCE device only.

转自：https://docs.microsoft.com/en-us/previous-versions/windows/embedded/cc510568%28v%3dmsdn.10%29

 

[MSDN] Overview of Advanced Audio Distribution Profile [A2DP] [Source Role]

 

 

 

Overview of Advanced Audio Distribution Profile (A2DP) (Source Role)

 

 

Windows Embedded NavReady supports the Bluetooth Advanced Audio Distribution Profile (A2DP). Bluetooth A2DP defines the protocols and procedures that let one Bluetooth-enabled device stream advanced audio from audio files to another Bluetooth-enabled device that has high-quality mono or stereo audio-output capabilities.

When a Windows Embedded NavReady powered portable navigation device (PND) supports the Source (SRC) role, it can stream advanced audio from audio alerts, turn-by-turn driving directions from a navigation application, or music content to an in-car media player. Then, the user can listen to the audio through in-car stereo speakers.

A2DP Roles

A2DP lets you create a Bluetooth channel through which advanced audio data is streamed from one Bluetooth-enabled device to another Bluetooth-enabled device.

Two roles are defined for Bluetooth-enabled devices that support A2DP:

• Source (SRC) role: a device is the SRC when it is the source of a digital-audio data and sends the stream to the SNK; for example, a portable navigation device (PND).
• Sink (SNK) role: a device is the SNK when it receives the digital-audio stream delivered from the SRC; for example, an in-car media player.

A Windows Embedded NavReady powered device supports the Source role only.

A2DP Architecture Overview

The following illustration shows the A2DP architecture:

The Windows Embedded NavReady powered device is the SRC that stores audio files in memory. The audio files can be part of a navigation application, or they can be obtained from a desktop media player through a connection to a desktop computer.

To start streaming audio data to a SNK device, the Windows Embedded NavReady powered device pairs to a device, and then searches the Service Discovery Profile (SDP) record on that paired device to determine whether the device supports A2DP. If it does support A2DP, the Windows Embedded NavReady powered device assumes the SRC role and uses the Audio Compression Manager (ACM) to send audio data over a Bluetooth connection.

The Windows Embedded NavReady powered device includes a waveform audio driver for features such as volume control and managing audio lines for playing digital-audio files. To route the audio data to a remote-output destination, the SRC device can use A2DP to stream the audio data over a Bluetooth link to a SNK device that supports mono or stereo audio-output capabilities, such as an in-car Bluetooth device. By using A2DP, audio data is compressed in a suitable format to effectively use bandwidth over a Bluetooth link.

The SNK device uses A2DP to receive the audio data and then uses its media player and audio driver to send it to an audio-output device, such as in-car stereo speakers.

A2DP depends on the General Access Profile in the Bluetooth stack, and also uses Audio/Video Distribution Transport Protocol to handle the streaming of audio data.

ActiveSync Desktop Pass-through (DTPT)

ActiveSync Desktop Pass-through (DTPT) is a technology that enables a Windows Embedded NavReady powered device to access files and features on a desktop computer through an ActiveSync connection that uses either USB, Bluetooth, infrared, or serial communications.

With DTPT, the device can establish a connection to a desktop computer and sync with the digital-audio collection stored on the desktop media player, such as Windows Media Player.

Benefits for Users

With support for A2DP and DTPT on a Windows Embedded NavReady powered portable navigation device (PND), users can store their digital-audio files on the PND and stay connected with their music and audio. Users can set up the PND to sync with their desktop media player. Then, they can copy their digital audio and music to the PND and enjoy their digital audio and music anywhere they go.

With a Bluetooth-enabled in-car media player that supports the Sink (SNK) role, it is easy to create a pairing relationship and use the in-car media player to stream audio to the in-car speakers through A2DP.

Users can also control playback of audio files from the SNK by using the Overview of Audio/Video Remote Control Profile (AVRCP) (Target Role).

Interaction Model for A2DP and Hands-Free Profile (HFP)

Windows Embedded NavReady supports connections to more than one Bluetooth-enabled device. However, the Hands-Free Profile (HFP) port and A2DP port on the Windows Embedded NavReady powered device supports being connected to only one device per profile at a time. They can be the same device, such as a Bluetooth system with a Subscriber Identity Module (SIM) card, phone capabilities, and stereo speakers. Or, one paired phone can be connected through HFP, and one paired in-car media device can be connected through A2DP.

If a user initiates an interaction to connect a new Bluetooth-enabled device to a profile port (HFP or A2DP) that is currently connected to another paired device, the previously-connected device will be disconnected, and the new device will be connected.

If an incoming voice call arrives through HFP, the audio stream through A2DP will be suspended until the hands-free voice call is disconnected.

Support for A2DP in an OS Design

To include support for A2DP, you must include the Advanced Audio Distribution Profile (A2DP) Catalog item (SYSGEN_BTH_A2DP) in your OS design.

To use A2DP to play audio on a Windows Embedded NavReady powered device, you must already have support in your run-time image for playing digital-audio files. For more information, see Waveform Audio.

There are no special A2DP code-implementation requirements to enable A2DP connections from a Windows Embedded CE powered device, other than including support for Bluetooth pairing, including the A2DP Catalog item, and optionally including the Audio/Video Remote Control Profile (AVRCP) Catalog item.

转自：https://docs.microsoft.com/en-us/previous-versions/windows/embedded/cc510655(v%3dmsdn.10)

 

Overview of Audio/Video Remote Control Profile (AVRCP) (Target Role)

 

 

Windows Embedded NavReady supports the Audio/Video Remote Control Profile (AVRCP) for the target role. AVRCP enables another Bluetooth-enabled device to send audio/video control commands to a Windows Embedded NavReady powered device. These commands control the playback of digital audio streamed through Advanced Audio Distribution Profile (A2DP).

With AVRCP, a Windows Embedded NavReady powered portable navigation device (PND) that is paired with an in-car media player can let the in-car media player control playback of the digital-audio files on the PND by using playback controls operated by the user. User interaction is usually required for using AVRCP.

AVRCP Roles

Two roles are defined for AVRCP:

• Controller (CT) role: the device in the CT role sends a command frame to a target; for example, an in-car media player.
• Target (TG) role: the device in the TG role receives a command frame and generates a response frame; for example, a portable navigation device (PND).

A Windows Embedded NavReady powered device supports the Target (TG) role only.

AVRCP Functionality

To enable receiving A/V commands from a CT device, the Windows Embedded NavReady powered device pairs to a device, and then searches the Service Discovery Profile (SDP) record on that paired device to determine whether the device supports AVRCP. If it does support AVRCP, the Windows Embedded NavReady powered device assumes the TG role in order to accept and respond to A/V commands sent over a Bluetooth connection to control playback of a digital-media file.

When audio is streaming over an A2DP Bluetooth connection, AVRCP enables the device in the Controller (CT) role to send command frames to the device in the Target (TG) role. Control messages are transported by using Audio/Video Control Transport Profile (AVCTP).

For more information about how audio is streamed by using Bluetooth profiles, see Overview of Advanced Audio Distribution Profile (A2DP) (Source Role).

For information about APIs that are used with AVRCP, see Bluetooth Profiles Reference.

AVRCP Catalog Item

To include support for AVRCP, you must include the Audio/Video Remote Control Profile (AVRCP) Catalog item (SYSGEN_BTH_AVRCP) in your operating-system (OS) design.

To implement support for receiving and handling AVRCP commands on a Windows Embedded NavReady powered device, you must include support for Bluetooth pairing, together with the AVRCP and A2DP Catalog items, and also implement a message queue for handling the AvcrpMsg message. For more information about the AVRCP API elements, see Bluetooth Profiles Reference.

转自：https://docs.microsoft.com/en-us/previous-versions/windows/embedded/cc510452(v%3dmsdn.10)

 

Overview of Dial-up Networking (DUN) Profile (Data Terminal Role)

 

 

 

Windows Embedded NavReady supports the Bluetooth Dial-up Networking (DUN) profile. Bluetooth DUN lets a Bluetooth-enabled device connect to another Bluetooth-enabled device that has a wireless modem, so that it can use that device as a modem to connect to the Internet or to other dial-up services.

With the DUN profile in Windows Embedded NavReady, you can enable users of a Windows Embedded NavReady powered portable navigation device (PND) to connect to the Internet through a Bluetooth link to a Bluetooth-enabled device that has a wireless modem. Then, users can send queries to a Live Search Engine, or can receive data from the Internet that is for a navigation application.

DUN Profile Roles

Two roles are defined for Bluetooth-enabled devices that support DUN:

• Data Terminal (DT) role: this role is for the device that requires access to the data network; for example, a portable navigation device (PND).
• Gateway role: this role is for the device that serves as modem. It enables the Data Terminal device to connect to a public network such as the Internet; for example, a mobile phone.

A Windows Embedded NavReady powered device supports the Data Terminal (DT) role only.

DUN Architecture Overview

The following illustration shows the Bluetooth DUN architecture:

With support for DUN, a Windows Embedded NavReady powered device can create a connection to a data network by using the capabilities of a paired Bluetooth-enabled device that supports Bluetooth DUN. The Windows Embedded NavReady powered device can use that paired device as a wireless modem.

An application that requires Internet connectivity can use Connection Manager to establish a dial-up networking connection. Dial-up networking enables a Windows Embedded NavReady powered device to access network resources from a remote location, such as a car environment.

When the application sends a connection request, Connection Manager uses the CSPRas connection service provider (CSP) to establish a dial-up networking connection. The Windows Embedded NavReady powered device internally calls ActivateBTDevice in order to first establish the Bluetooth DUN connection to the paired device.

The DUN profile is dependent on Serial Port Profile (SPP), which creates a Bluetooth link to another Bluetooth-enabled device. This Bluetooth link acts like a wireless serial cable.

Once the Bluetooth DUN link is established, the paired device serves as a modem for the Windows Embedded NavReady powered device that is in the Data Terminal (DT) role. At this point, the paired device has a connection to the Internet, and a Windows Embedded CE application can access this Internet connection through the Bluetooth link, thereby using the Gateway device as a wireless modem.

Using DUN Profile to Connect to the Internet

When the DUN profile is included in a run-time image and you use Connection Manager to create a data connection, the DUN profile is automatically utilized. For more information about how to connect by using Connection Manager, see How to Make a Data Connection by Using Connection Manager.

Alternately, you can create the connection manually. For more information about how to connect manually, see Creating a Data Connection That Uses Bluetooth DUN.

Support for DUN in an OS Design

To include support for the DUN profile, you must include the Pairing Service Catalog item (SYSGEN_BTH_PAIRSVC) in your OS design.

转自：https://docs.microsoft.com/en-us/previous-versions/windows/embedded/cc510743(v%3dmsdn.10)