You know Bluetooth technology is a good idea if your product satisfies the following six criteria:

Think about the following items:

To know whether Bluetooth technology is right for your product, you must consider:

Question whether or not you need to support all the following features:

Should your stack be hosted, embedded with application on host, or fully embedded?

Should you design your own PCB (cheap in volume), or buy in a module (faster and easier)?

Battery—if your product is not mains-powered, consider the impact of time spent in different modes on the battery life. Constantly running in scan modes might give you fast connection time, but it will also rapidly drain your batteries. Setting short windows of activity can give almost equivalent performance, and greatly extend your battery life.

The protocol stack hides the complexity of the wireless interface and presents, at its highest level, a software interface that resembles that of a wired connection.

Not all the differences between a wired and a wireless interface can be hidden. In particular, the steps required to find and connect to other devices are peculiar to wireless.

Bluetooth devices can contain various combinations of upper stack layers to support various profiles. The Bluetooth specification details a service discovery layer so that devices can find out what services are available and how to connect to them.

With Bluetooth devices, the user may not initially know that there are other Bluetooth devices nearby, so a method is required to find them. The Bluetooth equivalent of plugging in a cable is the forming of a connection.

    The checks on communications protocols and applications compatibility are actually done once a basic Bluetooth link is established, and are called service discovery.

The procedure used to find devices is called inquiry, and the procedure used to connect to devices is called paging. In both cases, one device transmits and receives on special sequences of frequencies that are known to all devices. The other device needs to be listening for the transmissions—if a transmission is received correctly, it sends out a reply. Since it knows the sequences used for inquiry and paging, it can work out the correct frequency on which to send the reply.

Only devices in Inquiry Scan can be discovered.

An inquiry is normally a periodic or user-initiated event.

An inquiry response contains all the information required to connect to a device by paging.

Only devices in Page Scan can accept connections, although they may choose to reject incoming connection requests.

If a page and connection request is successful, then the paging device becomes the master of the piconet and the paged device becomes the slave. An Asynchronous ConnectionLess (ACL) connection now exists between the two.

A master can have connections to several slaves, but a slave can only have a connection to a master. For the upper stack layers, this is the only difference between the two.

The application is responsible for maintaining accurate records of the services it offers in a service database.

An ACL and a Logical Link Control and Adaptation Protocol (L2CAP) connection must exist to a remote device before it can browse the service database using the Service Discovery Protocol (SDP).

The service database contains all the information required for a remote device to identify and connect to local Bluetooth services.

A remote device must conduct an SDP query before connecting to a local Bluetooth service, and must support a complementary profile.

Connecting to a service involves first opening L2CAP, then higher layer connections in turn, using the information from the SDP query.

The procedure for using a service is detailed in the appropriate Bluetooth profile.

Consider whether your application is suitable for power-managed operation.

Consider the constraints imposed by the application (e.g., maximum response times, characteristics of the data traffic, and so on).

Hold mode One-off event, allowing a device to be placed into hold mode for a negotiated period of time. Hold interval must be negotiated each time this mode is entered.

Sniff mode Slave periodically listens to the master and can power save for the remainder of the time. Important to note that data can be transferred while devices are in this mode and a SCO link may be active. Sniff intervals are negotiated once, before sniff is entered, and remain valid until sniff mode is exited.

Park mode Parked slave periodically synchronizes with the master and for the remainder of the time can power save. Data packets cannot be sent on a parked connection and the devices must be unparked before a SCO connection can be established. Furthermore, there cannot be an active SCO when its associated ACL is parked.

All other things being equal, the power consumption of a Bluetooth low power mode depends on the parameters negotiated before that mode is entered.

Page and inquiry scan also have a power consumption cost, so these should be entered only when necessary.

Secure for protection of data from eavesdroppers.

Create exclusive links between devices.

Authentication verifies that the other Bluetooth device is the device you believe it is, using a link key as the secret password.

Authorization grants permission to a device making a request to use a particular service.

Encryption encodes data being passed between two devices; it requires successful authentication.

The Security Manager, which resides in the protocol stack, manages Mode 2 security transparently to the application.

The Host Controller manages Mode 3 security if configured to do so by the application software.

The Security database is configured by the application and specifies when to trigger Mode 2 security procedures as well as which security measures are to be taken.

The device database offers persistent storage for parameters created during the successful completion of security and makes these available for future sessions to reduce security procedures required.

Mode 2 security is invoked when a client application attempts to establish a connection with the server application and can use authentication, authorization, and/or encryption.

Mode 3 security is triggered by the Host Controller when either an incoming or outgoing request for a radio connection is made. Authentication and/or encryption can be specified.

Application Programming Interfaces support the configuration of the type of security to use and offer a way to insert user input (PIN entry) when required.

Security measures are to be supported in many profiles, such that if another device wants to invoke a component of the security troika, it will be met with an appropriate response.

In many instances, implementing security is not made mandatory since this is left up to the discretion of the system designer. What is made mandatory in many instances is supporting security as mentioned previously.

Non-discoverable mode as configured into the Host Controller can prevent device detection during the Inquiry process.

Non-accessibility can prevent any device from establishing a radio connection, thereby preventing access.

Applications often have associated with them User IDs and passwords as further measures toward protecting information resident on a server. Authorization, the act of granting permission to a service, is another application-based security measure used by the OBEX transport layer.

The term service discovery is used to describe the way a networked device (or client) discovers available services on the network. Service discovery makes zero configuration networks possible—the user doesn’t have to manually configure the network.

Key features of a discovery protocol are: spontaneous discovery and configuration of network services, low (preferably zero) administrative requirements, automatic adaptation to the changing nature of the network (addition or removal of nodes or services), and interoperability across platforms.

Bluetooth Service Discovery is protocol-dependent; it mandates the use of the underlying Bluetooth communication protocol as the basis for service discovery. However, Bluetooth SDP could indeed be implemented using other underlying transport mechanisms, and higher-level protocols (such as TCP/IP) may be run over Bluetooth.

For a particular service (and there may be many services on one device) a service record contains a description of that service. The description takes the form of a sequence of service attributes, each one describing a piece of information about the service.

Within the SDP server, each service record is uniquely identified by a service record handle. A service class defines the set of service attributes that a particular service record may have. In other words, a service record is a particular instance of a class of services.

A service attribute is a name-value pair that includes an attribute ID and an attribute value. The attribute ID uniquely identifies the attribute within the scope of the service record.

An attribute value can contain data of arbitrary complexity, rather than just simple types. This is accomplished using data elements. A data element is made up of a header and a data field.

The Service Discovery Protocol includes a set of Protocol Data Units (PDUs) that contain the basic requests and responses needed to implement the functionality of Bluetooth Service Discovery. An SDP PDU contains a PDU ID, a transaction ID, and a parameter length in its header. Its body contains some number of additional parameters, depending on which type of transaction the PDU contains.

Every Bluetooth device can contain a Service Discovery Server (SDS) that advertises the services available on that particular device, be it a mobile phone, PDA, or something else. It can do this by making available the service records that describe those services.

The Bluetooth-defined Class of Device (CoD) value can tell a discovering device if a connection should be opened to the discovered device—it doesn’t have to open a connection to the SDS and check the Service Discovery Database (SDDB) of the discovered device, “short-circuiting” service discovery.

The Bluetooth Service Discovery Protocol allows for services to be discovered on the basis of a series of attributes with values of type UUID. In reality, when talking about discovering specific services, one of the most important attributes of a service, if not the most important, is the ServiceClassIDList.

The SDAP is a usage scenario describing the functionality a Service Discovery Application (SrvDscApp) should provide to an end user on a local device (LocDev) so that user can discover services on a Remote Device (RemDev). The SDAP doesn’t specify an API that will provide this functionality, but suggests primitives that can be mapped to an API.

Most profiles detailed in the Bluetooth specification have a service discovery component that specifies the structure and content of the service record that accompanies the service (or application) and which realizes the profile. The SDAP (in addition to dealing with application functionality for service discovery) specifies the procedures that an application realizing a profile must use to perform service discovery. If these procedures are upheld, interoperability is ensured.

As part of Java Community Process (JCP), a set of standard Java APIs for Bluetooth is being developed and is due for publication at the end of 2001. Implementations of this standard will allow programmers to implement Bluetooth applications within the J2ME environment in a standard and portable way.

A key element of the J2ME specification is the Generic Connection Framework (GCF), a mechanism that allows a programmer to create different types of networking connections through a standard Connector interface. This would allow programmers to quickly produce Java Bluetooth applications by applying existing techniques and design patterns.

The Bluetooth SDP may be integrated with a number of the other service discovery protocols, including Salutation, UPnP, Service Location Protocol (SLP), and Jini.

The Salutation architecture defines a uniform way of labeling devices (fax machines, printers, copiers, and also phones, PDAs, and general electronic equipment) with descriptions of their capabilities and with a single, common method of sharing that information.

Salutation is “transport independent,” that is, a separate Transport Manager may be written for each underlying transport required, and the Salutation Manager, which provides the core functionality of the system, remains transport neutral.

SLP is a language-independent protocol for automatic resource discovery on IP-based networks. Like some of the other service discovery protocols, it makes use of UDP/IP multicast functionality in TCP/IP. This makes it particularly useful for networks where there is some form of centralized administrative control, such as corporate and campus networks.

Jini is a distributed service-oriented architecture, considered an extension of the Java language and platform. Services communicate with each other using a service protocol, which is defined as a set of interfaces in Java. The standard itself provides a base set of interfaces to facilitate core interaction between services. A key component of Jini is the lookup service.

Communication between services in Jini occurs using Java Remote Method Invocation (RMI). RMI is a Java-based extension to traditional remote procedure call (RPC) mechanisms. One important extension is that it enables actual code, not just data, to be exchanged between services.

Universal Plug and Play (UPnP) defines a set of lightweight, open, IP-based discovery protocols that allow appliances to exchange and replicate relevant data between themselves and the PCs on the network. UPnP is a “wire-only” protocol—it defines the format and meaning of what is transmitted between members of the network and says nothing about how the standard is actually implemented. It requires TCP/IP and HTTP to be present to operate.

UPnP uses the Simple Service Discovery Protocol (SSDP) to discover services on IP-based networks. SSDP can be operated with or without a lookup or directory service in the network. SSDP operates on the top of the existing open standard protocols, using the HTTP over both Unicast UDP and Multicast UDP.

SDP is one of many protocols that deal with the concept of service discovery. One of the key issues is interoperability of the various protocols.

In the immediate future of SDP, the Bluetooth SIG is defining the Extended Service Discovery Protocol. This “new” protocol is expressed as a profile (dependent on the Generic Access Profile) and allows the Universal Plug and Play (UPnP) protocol suite to run over a Bluetooth stack. Though not proposed at present, a similar profile could be developed for the Jini service discovery protocol.

The standard kernel source tree only recently accepted the Bluez Bluetooth stack, but it may not yet possess all the features some application developers require. It requires Linux 2.4.4 or greater.

IBM’s BlueDrekar is a nice-looking implementation distributed in binary form for x86 platforms running 2.2.x. Source is not freely available to the general public.

The OpenBT project is a not-as-nice open source project that works for most things an embedded developer would want. Source is available and has been used on x86, ARM9, ARM7, MIPS, and PowerPCs.

The OpenBT stack implements TTY drivers for RFCOMM, SDP, and stack control.

The Bluetooth driver must be stacked over a lower-layer hardware driver that implements a TTY.

Any legacy application that uses a TTY can use RFCOMM once another application sets up the underlying RFCOMM connection.

SDP, connection setup, and stack control are accomplished with ioctl calls.

No interface exists for SCO, or L2CAP, although ioctls are available to support most HCI commands.

The OpenBT source tree comes with some applications: btd/btduser, sdp_server, and BluetoothPN.

The difference between btd and btduser is that btd is meant to work with the kernel mode Bluetooth driver while btduser works with the user mode Bluetooth driver. Many people prefer btduser since it is less prone to lock up your system if things go badly. However, the OpenBT developers do not support it as well as btd.

The sdp_server application provides you with an SDP database server daemon. Once you’ve installed the Bluetooth driver, you can start this daemon and it will automatically receive and respond to SDP queries from remote devices.

This application provides a GUI that displays the SDP database on a remote device. It provides some examples of how to make SDP requests and process their results.

The quickest, most useful way to establish and exploit a Bluetooth connection from Linux is to use the standard GNU network applications over PPP. And the easiest way to do that is with the btd application.

An application manager must set up the driver stack over the hardware TTY and initialize the Bluetooth driver. This can be any application; the OpenBT source tree does not provide a general stack manager.

Client applications must obtain the Bluetooth Device address of the remote device and—for RFCOMM connections—the channel number of the remote service in order to establish a connection.

Once a connection is established, any application can use the TTY associated with the connection for data transfer.

The driver indicates a disconnection event with a hang-up of the associated TTY.

Use ioctl calls to control the device and get information about device status.

Use /proc/bt_status to get information about device status.

A stack manager must be able to deal with link loss and system shutdown requests. It should provide an interface for users as well as other processes like power management to signal shutdown requests.

Embedded systems commonly have many tasks running simultaneously. Since the processor can only run one line of code at a time, a scheduler swaps between tasks running a few instructions from each in turn.

On BlueCore, your application task is called through an interpreter referred to as the Virtual Machine, which interprets a few of your instructions each time it is called. This interpreter means that even if you write code in an endless loop, the other tasks in the system will still get to run. The Virtual Machine’s interpreter also stops you from accessing areas of memory which are needed for other tasks.

Tasks communicate by sending messages to one another, using areas of memory which are set up as queues. The first message in the queue is the first out, so these are sometimes called FIFOs (First In First Out).

Application software can interact with hardware using interrupts. There are two pins on BlueCore which will generate an interrupt when they change state. An application can register to be notified when these interrupts happen.

When you close a switch, the contacts usually bounce off one another. This bouncing causes the switch to oscillate, making and breaking a connection. This means that if a switch (such as a pushbutton, or keypad) is connected to an interrupt line, you will get many interrupts as the switch closes. BlueLab provides debounce routines.

To create embedded applications to run on CSR’s BlueCore chip, you need BlueLab and a Casira. The Casira must be configured to run BCSP.

The PC is connected to the Casira with a serial cable and an SPI cable.

The Casira must be loaded with a null image containing an empty version of the Virtual Machine.

Applications running under the debugger on the PC can then use facilities on the Casira, so they can access PIO pins and the BlueCore chip’s radio while still having full PC debugging facilities.

You must make a special firmware build linking your application with a Virtual Machine build to run your application on the Casira.

Your application should be fully debugged before you build it for BlueCore, since on-chip debugging facilities are very limited.

You can communicate with the Virtual Machine on BCSP Channel 13 using VM Spy.

A selection of libraries provide ANSII C support as well as access to the Bluetooth protocol stack, PIO pins, and various operating system facilities such as scheduling, timers, messaging, and so on.

If you do not have RFCOMM in your build, you can upgrade devices in the field using the Device Firmware Upgrade (DFU) tools. Otherwise, you must program the flash using an interface similar to the SPI interface.

In order to begin using Bluetooth technology, you will need to have a Palm OS device with at least 4MB of memory that is running Palm OS version 4.0 or greater. Alternatively, you may wish to develop using the Palm OS Emulator, often the easiest and fastest way to create new application.

In addition to a Palm 4.0 device, you will need to have the BluetoothSupport Package installed. The Bluetooth Support Package consists of several .prc files that work together. The latest version of the Bluetooth support .prc files, along with the Bluetooth header files and several pieces of example code, can be found in the Bluetooth area of the Palm Resource Pavilion at www.palmos.com/dev/tech/bluetooth.

In addition, you will also want to have a copy of the Palm OS 4.0 SDK documentation, also available on the Palm, Inc. Web site.

The Palm OS currently supports five Bluetooth profiles defined in the Bluetooth 1.1 Specification: the Generic Access Profile, the Serial Port Profile, the Dial-up Networking Profile, the LAN Access Profile, and the Object Push Profile.

Generic Access Profile (GAP) is a general look at the overall process of carrying out a Bluetooth transaction without regard to the nature of that transaction, and is background for all the other profiles.

The new virtual serial driver (VDRV) in the Bluetooth Support Package provides support for the Serial Port Profile.

The Network Library (NetLib) supports the Data Terminal role of both the Dial-up Networking and LAN Access Profiles.

The new Bluetooth Exchange Library implements the Object Push Profile, much in the same way that the Exchange Manager supports IR-based Object Exchange Protocol (OBEX) push.

If none of the profiles cover what you are trying to do, don’t despair—the Palm OS also provides a robust API that allows you direct access to the SDP, RFCOMM, and Logical Link and Control Adaptation Protocol (L2CAP) layers of the Bluetooth stack, along with calls to allow you to manage the Bluetooth-specific concerns like discovery and piconet creation.

Using the Bluetooth Virtual Serial Driver allows existing serial-based applications to quickly be updated to take advantage of Bluetooth technology. The VDRV itself is “glue code” that allows Bluetooth functionality to be accessed though a more traditional API. Using the VDRV also gives you an advantage in writing multi-transport applications.

Virtual Serial Drivers in the Palm OS are individual .prc files of type vdrv and are used throughout the new Serial Manager interface, much the same way as traditional physical serial ports are used.

Since most Bluetooth radios are not capable of simultaneously listening for an inbound connection and trying to create an outbound connection, an instance of the Bluetooth VDRV also needs to know whether it is initiating or accepting the connection. Since a traditional serial API does not present a mechanism for passing all of this extra information, Palm OS 4.0 has added a new call, SrmExtOpen() (found in SerialMgr.h), to the new Serial Manager API.

A VDRV client-only application might be useful when you know that the Palm device will always be playing a client-based role, and therefore never need to accept a connection.

Applications and the VDRV use the Bluetooth Library in different modes. Because of this difference, the VDRV will not be able to open while the application is holding the Bluetooth stack open.

Setting up the serial port as a server does not cause the driver to go out and create an ACL or RFCOMM connection, it merely sets up the port as a listener. Like a normal serial port, the VDRV will not alert the application when an incoming connection is established, the application will simply begin to receive data from the port.

You can make an Exchange Manager-based application Bluetooth-aware with just a few lines of code. The Bluetooth Exchange Library registers itself for the exgSendScheme, so if you’ve already updated your application to take advantage of the exgSendScheme, it should work with Bluetooth technology as soon as you have installed the Bluetooth .prc files.

The Exchange Library allows applications to send data blocks without having to worry too much about the underlying transport.

The VDRV and Exchange Manager simplify using Bluetooth technology by encapsulating it inside familiar and easy to use interfaces, but the simplification also hides functionality and increases overhead.

If your application requires direct access to Bluetooth protocol layers or management functions, then you will need to make use of the Bluetooth Library (BtLib) API.

Even when using the Bluetooth Library directly, a Palm OS application cannot put the Palm device or the remote device into park, hold, or sniff modes. Also, while an application can request that a given link be authenticated or encrypted, for security reasons the application is not allowed to specify the authentication passkey or insist that a device be added to a list of trusted (or bonded) devices.

The Bluetooth Library API is fairly large, and can generally be divided into six sections: Common Library calls, management calls, socket calls, SDP calls, services calls, and security calls.

If your application is going to receive inbound connections, you should check to make sure the radio’s accessibility mode has been set to allow connection and (if desired) discovery. The accessible state of the device is determined by the user’s settings in the Bluetooth Preferences Panel.

If you plan to have your application create outbound Bluetooth connections, you will probably want to perform a device discovery in order to allow the user to select the remote device(s) with which she wished to create a connection. The Bluetooth Library offers two similar calls that handle the entire discovery experience, including inquiry, name retrieval, and user selection, BtLibDiscoverSingleDevice() and BtLibDiscoverMultipleDevices().

Bluetooth piconets have a star formation: one master connected to up to seven active slaves. Once a successful call BtLibPiconetCreate() call has been made, up to seven simultaneous ACL connections can be established. Depending upon the usage model for your application, you may wish to have the piconet master actively create outbound connections, wait for inbound connections from remote devices, or both.

The L2CAP and RFCOMM protocol layers are exposed in the Bluetooth API through a sockets-based interface. The ability to create and receive RFCOMM and L2CAP connections is entirely independent of the device’s role in a piconet.

Applications or protocols that run on top of L2CAP must be able to handle the flow control themselves, while applications that run on top of RFCOMM can make use of its built-in flow control. Also, an RFCOMM listener is only capable of supporting one connection at a time, while a L2CAP listener can receive an unlimited number of connections. If your application involves functionality covered by a Bluetooth profile, you will not have to make a choice of which layer to use, as the profiles provide guidance on how to use the Bluetooth protocol stack.

L2CAP identifies available listeners by a Protocol Service Multiplexor (PSM), which can be thought of as similar to an IP port. The RFCOMM protocol uses a simple enumeration called a Server ID to distinguish its listeners. You can let remote applications know which PSM and Server ID to connect to by advertising them with SDP.

The Bluetooth Library offers an extensive set of APIs for working with SDP.

The Palm OS allows services to run on an as-needed basis by implementing the OBEX service in the IR implementation. While the client side of OBEX starts up in response to a user action (the “beam” command), the service side of OBEX is brought up by the OS when an inbound IR connection is detected. Palm OS’s IR service implementation is able to avoid the overhead of the OBEX service and IR stack when they are not in use.

Although multiple services can be registered, once a given service begins a session, the other services become unavailable until it completes its session.

Services are simply pieces of code that register for and respond to Bluetooth service notifications, normal Service Manager notifications of type BtLibServiceNotifyType (btsv). When the application is launched in the normal manner, it displays controls that allow the user to enable and disable the service, which can correspond to registering and unregistering for the Bluetooth service notification.

In the near future, Bluetooth technology will address the issues of Layer 3 (Network level) support in the Bluetooth communication protocol stack. New specifications will define a network layer for communications between all the members of a piconet (not just master to slave), as well as inter-piconet communication issues.

Roaming and scatternets will also be addressed.

The eventual goal is the creation of true ad-hoc networks, self-configuring network groupings that grow and change as the user’s environment changes.

New editions of the Palm OS Bluetooth Library will expand the Palm OS’s Bluetooth capabilities without compromising existing applications.

Codecs (coder/decoders) convert between analog voice samples and the compressed digital format.

The output of the Codecs must be fed into the Bluetooth baseband as a direct input to the baseband (a technique commonly used in Bluetooth chips), or encapsulated in a Host Controller Interface (HCI) packet and fed across the Host Controller Interface.

Bluetooth technology uses CVSD and PCM Codecs. CVSD is more robust in the presence of errors, which is what makes CVSD attractive for use in Bluetooth systems. PCM is cheap and already available in many commercial devices.

There are two types of compression implemented in PCM Codecs: A-law and μ-law. The different types are used by phones in various geographical regions.

The Bluetooth system transmits data on ACL links and voice on SCO links. SCO links use periodically reserved slots, while ACL links do not reserve slots.

Live audio needs circuit switched channels to guarantee regular delivery of voice information—the receive Codecs need a regular feed of information to provide a good quality output signal. The circuit switched channels are the Synchronous Connection-Oriented links. They occupy fixed slots that are assigned by the master when the link is first set up.

Always remember that Bluetooth technology maintains a maximum of 3 × 64 Kbps full-duplex SCO voice packets. The SCO links provide voice quality similar to a mobile phone; if higher audio quality is desired, then compressed audio must be sent across ACL links.

Notice that we don’t want to modify the voice packets at the L2CAP layer. SCO packets bypass the L2CAP layer.

If you choose to send data at the same time as voice, you will also lose out on error protection on the voice links.

When a link is to be established, use the following procedure: scan or page for an audio device. Use SDP to identify service. Set up ACL connection first for control, then set up SCO connection. During a voice connection, control messages can be sent such as DTMF signals

There are two routes for audio: either a direct link between the baseband and the application layer, or through the HCI. All packets passing through HCI experience some latency.

If the Universal Asynchronous Receiver Transmitter (UART) HCI transport is used, there is no way to separately flow control voice and data, so when data transport is flow controlled, the flow of voice packets across the HCI will also stop. The USB transport provides a separate channel for voice packets; however, USB requires complex drivers.

Not every chip/chip set supports audio. Of those that do, most provide direct access to the baseband, but some do not support audio across HCI.

Three different profiles cover audio applications: the Headset profile, the Cordless Telephony profile, and the Intercom profile. If your product supports several services, it may be appropriate to implement more than one profile. If your application is not covered by one of the profiles, you will have to design a complete proprietary application yourself.

The Headset profile allows the audio signal from a telephone call to be transferred between an audio gateway (AG) and a headset. If you just want to transfer the audio part of a call without control information, then the Headset profile is small, simple, and definitely the one to use.

The Cordless Telephony profile allows incoming calls to be transferred from a base-station to a telephone handset. If you are implementing a base station to pass voice calls to and from a telephone network, then you should use the Cordless Telephony profile.

The Intercom profile allows telephone calls to be transferred across a Bluetooth link without involving a telephone network at all. If you need to initiate voice calls to other Bluetooth devices in the area, but are not passing them on to a network, then you should use the intercom profile.

The Cordless Telephony and Intercom profiles both use Telephony Control Protocol (TCS) commands for control and share the same disconnection procedure. The Headset profile controls the link with AT commands, and does not provide any commands for the headset to terminate the connection.

In this section, we looked in detail at how a particular profile could be implemented at application level. All inquiry, paging, scanning, and service discovery are the same no matter which profile you implement. Similarly, the audio must be routed into the Bluetooth subsystem somehow, regardless of the audio profile chosen.

The first step will be finding suitable devices in your neighborhood using the Bluetooth Device Discovery procedures.

Once the audio gateway application has found a device that belongs to the audio/headset class of devices, it needs to find out how to connect to the headset service. To do this, it uses Service Discovery Protocol (SDP) and performs a service search for the headset service.

Once the service discovery phase is complete, you can connect to an audio service. The first step is to set up an ACL link. This connection is used to create an L2CAP link using the PSM value for RFCOMM. Next, an RFCOMM channel is set up to control the headset. Once the audio gateway knows that the headset is willing to accept the call, it establishes an audio (SCO) link. The headset must be able to accept all Codecs and all packet types on the link.

Be sure to consider the weight, size, and form factor in your product design.

The user interface is the most crucial aspect of your application. Ask yourself if there are ways to hide the complexity of Bluetooth technology. Button functions and headset designs offer opportunities for improvement and differentiation.

Another way to differentiate your product is to provide ongoing support for new features or for future versions of the Bluetooth specification.

Improving design and engineering to better the audio path can have a noticeable impact for the user, helping to avoid audio feedback, acoustic coupling, and resonance effects.

The chip’s physical size is small, and there are many chip vendors to choose from.

The range is adequate—the lowest power version offers up to a 10 meter range, which is sufficient.

The available choice of chip vendors leads to a competitive market.

There is worldwide acceptance of the ISM band used by Bluetooth.

A Bluetooth-enabled Personal Information Base (PIB) system in our hospital case study would store all patient information and information about visits, prescriptions, x-rays, and test information. It would be encrypted for both doctors and patients, have a user-friendly interface with low resolution screen; and would have a wireless connection to a main computer or Data Access Terminal.

Data loss is avoided using automated backups. Automated backups are enabled by wireless communications.

Encryption and passwords may be used to prevent unauthorized access to data.

Use of radio devices may be restricted in some areas, so it should be possible to easily disable the Bluetooth transmitter.

For a Personal Information Base, the Object Push Profile can be used to exchange virtual business cards (vCards), which publicly identify a PIB’s owner. The File Transfer Profile can be used to exchange medical records.

The Object Push and File Transfer Profiles both rest on the Generic Object Exchange Profile, which uses the Infrared Data Association’s OBEX protocol to exchange data objects. This, in turn, relies on the Serial Port Profile.

By using Bluetooth profiles, the PIB application can employ standard protocol stacks and features. This enables applications to be easily integrated with existing Bluetooth protocol stacks.

In designing any Bluetooth application, usability is a potential barrier to adoption that should be considered. Ideally your application will work straight out of the box, with controls that are obvious to the uninitiated.

Do not redesign existing system interfaces if it is not necessary. Using legacy applications wherever possible can help to ease adoption of new technology.

The PIB device has many interfaces for communication and for interacting with it, but at the same time it must be extremely power-efficient. This means that the interfaces must only be active when they need to be. Ideally, a PIB device should be able to last one week before the battery needs to be replaced.