The task of interoperability, therefore, has fallen on the design engineering community. To ensure interoperability, vendors must work with other vendors to ensure that Bluetooth interoperability can be achieved.

When running interoperability tests, there are a few key parameters that design engineers should be examining. Issues such as service discovery, PPP connection, and data throughput must be addressed. Here's a guide that will help you sort through some of these key interoperability tests. [Note: In this article we will describe the connection between a Bluetooth client and an access point (AP). Some of these same principles can be applied to interoperability tests run between clients.]

Device Discovery
Often, device discovery is the first step in setting up the Bluetooth connection. If the client does not discover the AP, engineers should first check the client configuration settings for device discovery. Sometimes this is limited to looking for specific devices (filtered by their Bluetooth address or class of device), a specific number of devices, or only trusted devices. Also, a client might be listening for inquiry responses for a limited time period only.

Failure can also be due to settings on the AP. Check the AP's Bluetooth configuration settings to ensure it is not set to "undiscoverable." This is sometimes done for security purposes to exclude clients from using the AP.

If there are other Bluetooth clients connecting, it is possible that the AP has reached the limit of the number of clients it can serve. When that happens, the AP is not discoverable to new clients anymore.

Service Discovery
Once devices discover each other on a network, they perform service discovery to see what types of profiles the other device supports.

A few issues can cause headaches for service discovery. Sometimes discovery can fail because of the security policy in the AP, which may prevent unauthorized clients from discovering services, or even making a Bluetooth asynchronous connectionless (ACL) connection in order to identify profiles. In security mode 3, the client will be required to enter a passkey to complete the ACL connection, and this passkey should be configured on the AP as well. In security mode 2, all clients can connect and browse for available services, but unauthorized clients will be prevented from connecting.

Another likely cause for service discovery failure is not being able to role switch. When a client activates the ACL connection for service discovery, it will initially be designated as the master of the connection. However, once the connection request reaches the AP, the AP will instruct the client to switch roles and become a slave. This allows the AP to remain the master of the piconet and continue to serve other clients. If the client fails to switch roles within a specific time period, the AP will disconnect the device.

Bluetooth Connection
There are two steps that must be taken to ensure Bluetooth connectivity. First, the client needs to establish a Bluetooth connection to the AP, and second, it needs to establish a PPP connection to the AP. The Bluetooth connection must actually occur at multiple levels such as baseband, L2CAP, and RFCOMM. However, everything is abstracted into a single connection step for the client user.

As stated above, security settings are a typical source of Bluetooth connection failure. An AP can have different policies for security, and might filter unauthorized clients based on their Bluetooth address and passkey. During the connection process, the client will be prompted to enter the passkey, which must match the one stored in the AP. Sometimes the AP will support a default passkey, such as "12345." It is important the client and the AP support compatible passkey lengths, which can range from one to 16 characters.

There are also certain Bluetooth protocol settings that can prevent a connection from being established. For example, the client and the AP must be able to agree on a common RFCOMM frame size. They must also support a common flow control mechanism. Bluetooth specification version 1.1 requires devices to support a credit-based flow control mechanism.

PPP Connection
After establishing a Bluetooth connection successfully, the client must setup the PPP connection. Even before attempting to initiate the PPP connection, it is useful to check the dialer settings on the client. For example, the dialer must use the correct COM port, security and network settings must be compatible with the configuration of the AP, and so forth.

If the AP is configured to do PPP authentication, it is necessary to have a username and password configured in the AP. This information must match what the client supplies. The actual protocol used for authentication--password authentication protocol (PAP) of challenge handshake authentication protocol (CHAP)--must also be supported by both sides.

PPP protocols are used by the AP to configure the client with network settings such as IP address, default gateway, DNS and WINS server addresses. For the client to obtain these settings correctly, it is necessary that the AP be able to obtain these values, either through static configuration or via DHCP from an LAN-based DHCP server. If the client does not obtain the appropriate settings, it may result in an inability to connect to sites using domain name (e.g. Web sites) or even IP addresses.

Data Transfer/Throughput
Once the PPP connection is established, the client can send and receive data from the LAN through the AP. One of the first attributes users notice is the connection speed, which can vary based on the capabilities of the client and AP, RF conditions, and application characteristics.

A key factor in determining throughput is packet size. At the IP layer in the client operating system, a maximum transmission unit (MTU) size is set, which is typically 576 B for Windows 98 and 1500 B for Windows 2000. PPP encapsulates IP packets, adding a frame check sequence (FCS) to indicate errors in receiving the data at the other end. The resulting octet stream is then sent to RFCOMM, which packages it into a frame with its own header.

The RFCOMM frame size is negotiated at Bluetooth connection setup time. It is best to set the RFCOMM frame size such that it can accommodate the largest IP packet (plus PPP overhead bytes) in a single RFCOMM frame. Typical RFCOMM frame sizes used by commercial clients are 128, 326, 660 and 2386 bytes.

Credit flow control was introduced in the Bluetooth 1.1 spec to help manage RFCOMM frame size and is slowly being implemented in commercial Bluetooth devices. If credits are not granted at the right time, they can slow down the data transfer and in the case of an incorrect implementation, can prevent data transfer altogether. This happens when the receiver thinks it has granted some credits to the sender, but the latter has run out of actual credits to transmit data.

The RFCOMM frame size is inversely related to the number of credits granted for flow control. A larger RFCOMM frame size will result in fewer credits being granted. If the application sends small packets (which is typical during Web surfing), then the result may be underutilization of receive buffers. In the extreme case, the sending side can run out of credits and have to wait to get a credit update, even though there are plenty of receive buffers at the other end.

An important aspect of credit flow control is that if a packet is lost below RFCOMM, it can confuse the credit allocation scheme. For example, if the lost packet had a credit update, it would result in a mismatch between the sender and the receiver. In this scenario, the Bluetooth stack on the receiver typically drops the connection entirely. This is a rather severe treatment of a lost packet, but one that is necessitated by the credit flow control mechanism in RFCOMM.

Baseband Packets
Data is transmitted over the air using baseband packets. The master (AP) controls what device gets to send data and how much. A significant determinant of throughput is the baseband packet payload size, which can vary from 17 B for DM1 packets to 339 B for DH5 packets. Since each baseband packet has the same header, a larger payload results in higher throughput. The baseband generally picks the largest packet size based on available RF conditions. However, it can be instructed to use only certain packet sizes.

Throughput can be affected significantly by RF conditions. If there are many interfering sources in the 2.4 GHz band, such as other Bluetooth or 802.11b radios, microwaves, or cordless phones, then the baseband packets can get corrupted over the air. When that happens, the receiving baseband does not acknowledge the packet and the sender has to retransmit.

Excessive retransmissions chew up available bandwidth and reduce throughput. High error rates also result in the baseband using more robust, smaller packet types such as DM1 and DM3 that provide greater error protection, but lower bit rate. Increasing transmit power or closer placement of the communicating Bluetooth devices can somewhat mitigate interference from other sources.

Application Issues
A common mistake is to blame the Bluetooth connection for poor application connectivity or throughput when there are other application or network level issues that may be the cause.

Slow throughput can be due to an overloaded network or a slow server. Sometimes the server is not available, or the client may be misconfigured to use the wrong name or address for the server. If the application transport uses TCP, then TCP flow control will affect the data throughput.

Another issue could be the network address translation (NAT) function in the AP. Most APs are set to assign an IP address to the client using a NAT subnet address and subnet mask. When the client sends data to the LAN, the AP translates it so the source IP address and port are mapped to the AP's own IP address and a unique port ID assigned for this data session. The reverse mapping takes place on incoming data to the client. Certain applications do not work well with NAT in place. For example, certain VPN applications require the client to have a non-NAT address.

Tools
There are a number of tools that can be used to diagnose interoperability issues. By far, the most useful is Bluetooth RF sniffer, which can decode Bluetooth packets. This sniffer can capture all over-the-air traffic, and can provide decoding all the way from baseband to RFCOMM. This can help to identify issues such as RF interference causing packet errors, packet retransmissions, sequencing, credit updates, etc.

An RF signal strength analyzer can provide more insight on the type of RF interference that may be causing packet errors and retransmissions. Different sources, such as 802.11b radios, microwaves, and cordless phones, have different patterns of usage in the 2.4 GHz ISM band. Further, this analyzer can measure signal strengths to provide an indication of transmit power levels and receiver sensitivities.

Network packet sniffers can capture and decode application traffic over the Ethernet LAN, and together with the RF sniffer trace, can be used to effectively correlate the traffic to analyze where the errors may have occurred.

If needed to debug the Bluetooth implementation itself, one can enable debug printing in the Bluetooth software and hook up a console to monitor the resulting log. Different levels of logs can provide different levels of information, although such logging will have a negative impact on system throughput, and should only be used selectively for debug purposes.

If the host controller interface (HCI) interface between the baseband and the host stack is accessible over an external USB interface, as is the case with most client Bluetooth USB adaptors, then a USB sniffer can also be interjected between the Bluetooth USB adaptor and the host PC to capture the flow of packets across HCI. This can also be used along with the RF trace to correlate the traffic and analyze errors.

About the Author
Rajeev Gupta is senior director of software at Pico Communications, Inc. Prior to that, Rajeev was the Senior Director of Technology at EmpowerTel Networks. Rajeev holds a B. Tech (Computer Science & Eng) from IIT, Delhi and an MS (Computer Science) from UCLA. He can be reached at Rajeev@pico.net".