Getting Start with 32feet ( Part 1 ) : General Information About Bluetooth
What is Bluetooth and how does it work?
http://archive.devx.com/wireless/articles/Bluetooth/BtoothFAQ.asp
What is the bluetooth services Profiles?
Bluetooth Wireless Technology Profiles
In order to use Bluetooth wireless technology, a device must be able to interpret certain Bluetooth profiles. The profiles define the possible applications. Bluetooth profiles are general behaviors through which Bluetooth enabled devices communicate with other devices. Bluetooth technology defines a wide range of profiles that describe many different types of use cases. By following a guidance provided in Bluetooth specifications, developers can create applications to work with other devices also conforming to the Bluetooth specification.
At a minimum, each profile specification contains information on the following topics:
- Dependencies on other profiles
- Suggested user interface formats
- Specific parts of the Bluetooth protocol stack used by the profile. To perform its task, each profile uses particular options and parameters at each layer of the stack. This may include an outline of the required service record, if appropriate
Advanced Audio Distribution Profile (A2DP)
A2DP describes how stereo quality audio can be streamed from a media source to a sink. The profile defines two roles of an audio source and sink. A typical usage scenario can be considered as the “walkman” class of media player. The audio source would be the music player and the audio sink is the wireless headset. A2DP defines the protocols and procedures that realize distribution of audio content of high-quality in mono or stereo on ACL channels. The term “advanced audio”, therefore, should be distinguished from “Bluetooth audio”, which indicates distribution of narrow band voice on SCO channels as defined in the baseband specification.
This profile relies on GAVDP. It includes mandatory support for low complexity subband codec (SBC) and supports optionally MPEG-1,2 Audio, MPEG-2,4 AAC and ATRAC.
The audio data is compressed in a proper format for efficient use of the limited bandwidth. Surround sound distribution is not included in the scope of this profile.
Audio / Video Control Transport Protocol (AVCTP)
AVCTP describes the transport mechanisms to exchange messages for controlling A/V devices.
Audio / Video Distribution Transport Protocol (AVDTP)
AVDTP defines A/V stream negotiation, establishment and transmission procedures.
Audio/Video Remote Control Profile (AVRCP)
AVRCP is designed to provide a standard interface to control TVs, hi-fi equipment, or other to allow a single remote control (or other device) to control all the A/V equipment that a user has access to. It may be used in concert with A2DP or VDP.
AVRCP defines how to control characteristics of streaming media. This includes pausing, stopping and starting playback and volume control as well as other types of remote control operations. The AVRCP defines two roles, that of a controller and target device. The controller is typically considered the remote control device while the target device is the one whose characteristics are being altered. In a “walkman” type media player scenario, the control device may be a headset that allows tracks to be skipped and the target device would be the actual medial player.
This protocol specifies the scope of the AV/C Digital Interface Command Set (AV/C command set, defined by the 1394 trade association) to be applied, realizing simple implementation and easy operability. This protocol adopts the AV/C device model and command format for control messages and those messages are transported by the Audio/Video Control Transport Protocol (AVCTP).
In AVRCP, the controller translates the detected user action to the A/V control signal, and then transmits it to a remote Bluetooth enabled device. The functions available for a conventional infrared remote controller can be realized in this protocol. The remote control described in this protocol is designed specifically for A/V control only.
Basic Imaging Profile (BIP)
BIP defines how an imaging device can be remotely controlled, how an imaging device may print, as well as how an imaging device can transfer images to a storage device. BIP also includes the ability to resize and convert images to make them suitable for the receiving device. A typical scenario involves a mobile phone being used to control the shutter operation of a digital camera.
BIP may be broken down as follows:
- Image Push: Allows the sending of images from a device the user controls
- Image Pull: Allows the browsing and retrieval of images from a remote device
- Advanced Image Printing: Print images with advanced options using the DPOF format
- Automatic Archive: Allows the automatic backup of all the new images from a target device
- Remote Camera: Allows the initiator to remotely use a digital camera
- Remote Display: Allows the initiator to push images to be displayed on another device
Basic Printing Profile (BPP)
BPP allows devices to send text, e-mails, vCards, images or other items to printers based on print jobs. It differs from HCRP in that it needs no printer-specific drivers. This makes it more suitable for embedded devices such as mobile phones and digital cameras which cannot easily be updated with drivers dependent upon printer vendors.
BPP defines two roles, a sender and a printer. The sender is typically the mobile device such as a mobile phone or PDA which desires to print without the overhead of a driver. The printer is the device which renders the information to be printed. This is typically a physical printer or PC acting as a proxy for a printer connected via another physical transport such as USB.
BNEP
BNEP is used to transport common networking protocols over the Bluetooth media such as IPv4 and IPv6. The packet format is based on EthernetII/DIX Framing as defined by IEEE 802.3 (runs directly over L2CAP). BNEP is used by the Personal Area Networking Profile (PAN).
Common ISDN Access Profile (CIP)
CIP defines how ISDN signaling can be transferred via a Bluetooth wireless connection. CIP provides unrestricted access to the services, data and signaling that ISDN offers.
The purpose of the Common ISDN Access Profile (CIP) is as follows:
- To define how applications shall access ISDN over Bluetooth technology
- To allow wherever possible unrestricted access to services, data or signaling provided by ISDN
- To ensure that legacy ISDN applications do continue to work without any modification inside that application itself
- To define how the ISDN access co-exists with Bluetooth specifications that possibly access ISDN in one way or another
- To show how ISDN over Bluetooth technology can co-exist with existing ISDN in one application
Cordless Telephony Profile (CTP)
CTP defines how a cordless phone can be implemented over a Bluetooth wireless link. This profile can be used for either a dedicated cordless phone or a mobile phone that acts as a cordless phone when in proximity to a base station implementing the CTP. It is anticipated that mobile phones could use a Bluetooth CTP gateway connected to a landline when within the home, and the mobile phone network when out of range. CTP is central to the Bluetooth technology '3-in-1 phone' use case.
Dial-up Networking Profile (DUN)
DUN provides a standard to access the Internet and other dial-up services over Bluetooth technology. The most common scenario is accessing the Internet from a laptop by dialing up on a mobile phone wirelessly. It is based on SPP and provides for relatively easy conversion of existing products, through the many features that it has in common with the existing wired serial protocols for the same task. These include the AT command set specified in ETSI 07.07 and PPP.
Like other profiles built on top of SPP, the virtual serial link created by the lower layers of the Bluetooth protocol stack is transparent to applications using the DUN profile. Thus, the modem driver on the data-terminal device is unaware that it is communicating over Bluetooth technology. The application on the data-terminal device is similarly unaware that it is not connected to the gateway device by a cable.
DUN describes two roles, the gateway and terminal devices. The gateway device provides network access for the terminal device. A typical configuration consists of a mobile phone acting as the gateway device for a personal computer acting as the terminal role.
Extended Service Discovery Profile (ESDP)
ESDP defines how universal plug and play runs over a Bluetooth wireless technology connection.
Fax Profile (FAX)
The FAX profile defines how a FAX gateway device can be used by a terminal device. FAX is intended to provide a well defined interface between a mobile phone or fixed-line phone and a PC with FAX software installed. Support must be provided for ITU T.31 and / or ITU T.32 AT command sets as defined by ITU-T. A typical configuration is a personal computer using a mobile phone as a FAX gateway to send a FAX transmission to an arbitrary recipient.
File Transfer Profile (FTP)
FTP defines how folders and files on a server device can be browsed by a client device. Once a file or location is found by the client, a file can be pulled from the server to the client, or pushed from the client to the server using GOEP. The FTP profile includes support for getting folder listings, changing to different folders, getting files, putting files and deleting files. FTP uses OBEX as a transport and is based on GOEP.
FTP also defines client and server device roles and describes the range of their responsibilities in various scenarios. For example, if a client wishes to browse the available objects on the server, it is required to support the ability to pull from the server a folder-listing object. Likewise, the server is required to respond to this request by providing the folder-listing object.
Generic Access Profile (GAP)
GAP provides the basis for all other profiles and defines a consistent means to establish a baseband link between Bluetooth enabled devices. In addition to this, GAP defines the following:
- The features must be implemented in all Bluetooth devices
- Generic procedures for discovering and linking to devices
- Basic user-interface terminology
GAP ensures a high degree of interoperability between applications and devices. It also makes it easier for developers to define new profiles by leveraging existing definitions.
GAP handles discovery and establishment between devices that are unconnected. The profile defines operations that are generic and can be used by profiles referring to GAP and by devices implementing multiple profiles. GAP ensures that any two Bluetooth enabled devices, regardless of manufacturer and application, can exchange information via Bluetooth technology in order to discover what type of applications the devices support. Bluetooth enabled devices not conforming to any other Bluetooth profile must conform to GAP to ensure basic interoperability and co-existence.
General Audio/Video Distribution Profile (GAVDP)
GAVDP provides the basis for A2DP and VDP, the basis of the systems designed for distributing video and audio streams using Bluetooth technology. GAVDP defines two roles, an initiator and an acceptor. In a typical usage scenario, a device such as a “walkman” is used as the initiator and a headset is used as the acceptor.
GAVDP specifies signaling transaction procedures between two devices to set up, terminate and reconfigure streaming channels. The streaming parameters and encode/decode features are included in A2DP and VDP which depend on this profile.
Generic Object Exchange Profile (GOEP)
GOEP is used to transfer an object from one device to another. The object may be any object such as a picture, document, business card, etc. The profile defines two roles, a server that provides the location form which an object is pulled or pushed, as well as a client that initiates the action. Applications using GOEP assume that links and channels are established as defined by the GAP. The GOEP is dependent on the Serial Port Profile.
GOEP provides a generic blueprint for other profiles using the OBEX protocol and defines the client and server roles for devices. As with all OBEX transactions, GOEP stipulates that the client shall initiate all transactions. The profile does not, however, describe how applications should define the objects to exchange or exactly how the applications should implement the exchange. These details are left to the profiles that depend on GOEP, namely OPP, FTP and SYNC. Typical Bluetooth enabled devices using this profile are notebook PCs, PDAs, mobile phones and smart phones.
Hands-Free Profile (HFP)
HFP describes how a gateway device can be used to place and receive calls for a hand-free device. A typical configuration is an automobile using a mobile phone for a gateway device. In the car, the stereo is used for the phone audio and a microphone is installed in the car for sending outgoing audio. HFP is also used for a personal computer to act as a speaker phone for a mobile phone in a home or office environment. HFP uses SCO to carry a mono, PCM audio channel.
Hard Copy Cable Replacement Profile (HCRP)
HCRP defines how driver-based printing is accomplished over a Bluetooth wireless link. The profile defines a client and a server role. The client is a device containing a print driver for the server on which the client wishes to print. A common configuration is a client personal computer printing using a driver to a printer acting as a server. This provides a simple wireless alternative to a cable connection between a device and a printer. HCRP does not set a standard regarding the actual communications to the printer, so drivers are required specific to the printer model or range. This makes this profile more problematic for embedded devices which must update drivers. HCRP runs directly over L2CAP to avoid the overhead of RFCOMM / OBEX.
Headset Profile (HSP)
The HSP describes how a Bluetooth enabled headset should communicate with a computer or other Bluetooth enabled device such as a mobile phone. When connected and configured, the headset can act as the remote device’s audio input and output interface. The HSP relies on SCO for audio and a subset of AT commands from GSM 07.07 for minimal controls including the ability to ring, answer a call, hang up and adjust the volume.
Human Interface Device Profile (HID)
The HID profile defines the protocols, procedures and features to be used by Bluetooth HID such as keyboards, pointing devices, gaming devices and remote monitoring devices. The HID profile uses the universal serial bus (USB) definition of a HID device in order to leverage the existing class drivers for USB HID devices. The HID profile describes how to use the USB HID protocol to discover a HID class device’s feature set and how a Bluetooth enabled device can support HID services using the L2CAP layer. The HID profile is designed to enable initialization and control self-describing devices as well as provide a low latency link with low power requirements.
Intercom Profile (ICP)
ICP defines how two Bluetooth enabled mobile phones in the same network can communicate directly with each other without using the public telephone network. This function enables for example, the interconnecting of phones within an office. This profile has also been referred to as the walkie-talkie profile. It is a TCS based profile, relying on SCO to carry the audio.
Object Exchange (OBEX)
OBEX is a transfer protocol that defines data objects and a communication protocol two devices can use to exchange those objects. OBEX is designed to enable devices supporting infrared communication to exchange a wide variety of data and commands in a resource-sensitive standardized fashion. OBEX uses a client-server model and is independent of the transport mechanism and transport API. A Bluetooth enabled device wanting to set up an OBEX communication session with another device is considered to be the client device. The OBEX protocol also defines a folder-listing object, which is used to browse the contents of folders on remote device. RFCOMM is used as the main transport layer for OBEX.
OBEX enables applications to work over the Bluetooth technology protocol stack as well as the IrDA stack. For Bluetooth enabled devices, only connection-oriented OBEX is supported. Three application profiles have been developed using OBEX which include SYNC, FTP and OPP.
Object Push Profile (OPP)
OPP defines the roles of push server and push client. These roles are analogous to and must interoperate with the server and client device roles that GOEP defines. It is called push because the transfers are always instigated by the sender (client), not the receiver (server). OPP focuses on a narrow range of object formats to maximize interoperability. The most common acceptable format is the vCard. OPP may also be used for sending objects such as pictures or appointment details.
Personal Area Networking Profile (PAN)
PAN describes how two or more Bluetooth enabled devices can form an ad-hoc network and how the same mechanism can be used to access a remote network through a network access point. The profile roles include the network access point, group ad-hoc network, and PAN user. Network access points can be a traditional LAN data access point while group ad-hoc networks represent a set of devices that are only attached to one another. PAN is intended to allow the use of BNEP on Layer 3 protocols for transport over a Bluetooth wireless technology link.
RFCOMM
The RFCOMM protocol emulates the serial cable line settings and status of an RS-232 serial port and is used for providing serial data transfer. RFCOMM connects to the lower layers of the Bluetooth protocol stack through the L2CAP layer. By providing serial-port emulation, RFCOMM supports legacy serial-port applications while also supporting the OBEX protocol among others. RFCOMM is a subset of the ETSI TS 07.10 standard, along with some Bluetooth-specific adaptations.
Service Discovery Protocol (SDP)
SDP defines how a Bluetooth client application acts to discover an available Bluetooth enabled server services and characteristics. SDP provides means for the discovery of new services becoming available when the client enters an area where a Bluetooth enabled server is operating. SDP also provides functionality for detecting when a service is no longer available. SDP defines a service as any feature that is usable by another Bluetooth device. A single Bluetooth enabled device can be both a server and a client of services. An SDP client communicates with an SDP server using a reserved channel on an L2CAP link to find out what services are available. When the client finds the desired service, it requests a separate connection to use the service. The reserved channel is dedicated to SDP communication so that a device always knows how to connect to the SDP service on any other device. An SDP server maintains its own SDP database, which is a set of service records that describe the services the server offers. Along with information describing how a client can connect to the service, the service record contains the service’s UUID, or universally unique identifier.
Service Discovery Application Profile (SDAP)
SDAP describes how an application should use SDP to discover services on a remote device. As required by the GAP, any Bluetooth enabled device should be able to connect to any other Bluetooth enabled device. Based on this, SDAP requires that any application be able to find out what services are available on any Bluetooth enabled device it connects to. The profile handles the search for known and specific services as well as searches for general services. SDAP involves an application, the service discovery user application, which is required in a Bluetooth device for locating services. This application interfaces with the SDP that sends and receives service inquiries to and from other Bluetooth enabled devices. SDAP is dependent on and re-uses parts of the GAP.
SIM Access Profile (SAP)
SAP allows devices such as car phones with built in GSM transceivers to connect to a SIM card in a Bluetooth enabled phone. Therefore the car phone itself does not require a separate SIM card.
Serial Port Profile (SPP)
SPP defines how to set-up virtual serial ports and connect two Bluetooth enabled devices. SPP is based on the ETSI TS07.10 specification and uses the RFCOMM protocol to provide serial-port emulation. SPP provides a wireless replacement for existing RS-232 based serial communications applications and control signals. SPP provides the basis for the DUN, FAX, HSP and LAN profiles. This profile supports a data rate of up to 128 kbit/sec. SPP is dependent on GAP.
Synchronization Profile (SYNC)
The SYNC profile is used in conjunction with GOEP to enable synchronization of calendar and address information (personal information manager (PIM) items) between Bluetooth enabled devices. The profile also describes how an application can support automated synchronization. A common application of this profile is the exchange of data between a PDA and computer. SYNC defines client and server device roles. The profile is also commonly referred to as IrMC synchronization.
Telephony Control Specification (TCS-Binary or TCP)
TCP defines how a Bluetooth enabled device can be used as wireless phone and how a Bluetooth enabled mobile phone should switch to Bluetooth enabled wireless phone-function when it comes within reach of a Bluetooth enabled base station. TCP is a bit oriented protocol that defines the call control signaling for the establishment of speech and data calls between Bluetooth enabled devices. It also defines the signaling for the handling of groups of Bluetooth enabled devices. TCP also supports the establishment of a voice or data call in a point-to-point configuration or point-to-multipoint configuration. This protocol is based on the ITU-T recommendation Q.931 and runs directly over L2CAP.
Video Distribution Profile (VDP)
VDP defines how a Bluetooth enabled device streams video over Bluetooth wireless technology. Sample use cases include the streaming of a stored video from a PC media center to a portable player or streaming from a digital video camera to a TV. The profile mandates support for H.263 baseline. The support for MPEG-4 visual simple profile and H.263 profiles 3 and 8 are optional and covered in the specification.
WAP Over Bluetooth Profile (WAP)
WAP defines how the wireless application protocol suite can run over a Bluetooth wireless technology link. A typical configuration is a mobile phone connecting to a public kiosk over a Bluetooth technology link and using WAP to browse for information. WAP works across a variety of WAN technologies bringing the Internet to mobile devices. Bluetooth technology can be used to provide a bearer for transporting data between the WAP client and an adjacent WAP server. The ad hoc networking capabilities offered by Bluetooth technology gives a WAP client unique possibilities regarding mobility compared with other WAP bearers. The traditional form of WAP communications involves a client device that communicates with a server/proxy device using the WAP protocols. WAP technology supports server push. Used over Bluetooth technology, this protocol offers many possibilities for distributing information to handheld devices on location basis.
-----------------------------------------------------------------------------------
Source: http://www.bluetooth.com/Bluetooth/Learn/Works/Profiles_Overview.htm
End of Part 1
Regards,
zaaterah