Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > RF/Microwave

Fundamentals of the Bluetooth protocol

Posted: 16 Aug 2007 ?? ?Print Version ?Bookmark and Share

Keywords:Bluetooth? protocol fundamentals? protocol stacks?

By Larry Mittag
Mittag Enterprises

The Bluetooth protocol was created by a consortium of companies outside the purview of the IEEE. The thinking behind this was that the personal-area networks (PANs) that were envisioned were going to happen too quickly to allow the ponderous process of consensus that IEEE utilizes.

It was believed that a focused group of interested companies could significantly shorten the time required and get to market much quicker.

As it turned out, this was not necessarily the case. Bluetooth certainly got into the public eye much more quickly, but by the time a workable standard was actually delivered most of the interest of the wireless world was on the 802.11b networking standard.

This is particularly troubling, since applications that are relevant to WLANs are often not particularly well-suited to PANs, and vice versa. Unfortunately, Bluetooth had also lost its focus on the mission of replacing the tangle of specialty cables that hinder any number of small devices from cellphones to PDAs to iPods. As a result, many engineers overlook Bluetooth for applications for which it would be a very good solution.

Technical details
The Bluetooth Consortium took a very different approach than the 802.11 Committee did. Rather than build Bluetooth as an adjunct to TCP/IP, Bluetooth was built as a standalone protocol stack that included all layers required by an application. This meant that it included not only wireless communications but also service advertisement, addressing, routing and a number of application-level interfaces referred to as profiles. Version 1.1 of the Bluetooth Core Specification weighed in at a hefty 1200 pages! Needless to say, I will not be covering it in such detail here.

Bluetooth is based on a FHSS modulation technique that hops at a very fast rate (1600 hops per second) and has a symbol rate of about 1Mbps. This translates to about 700Kbps of actual useful data transfer. (Bluetooth EDR, which was adopted in 2006, has a considerably higher data rate).

Bluetooth networks are organized in piconets, which contain one master and a number of slaves. Bluetooth nodes can simultaneously be members of different piconets, but they cannot be masters in more than one at a time.

Overlaid piconets that include common members are referred to as scatternets. The primary elements of the Bluetooth stack are shown in the figure below. As with a typical diagram of the TCP/IP stack, there are a number of details that are hidden by the apparent simplicity of the stack.

Bluetooth protocol stack.

Specifically, there are a number of profiles that sit roughly on top of the L2CAP layer that provide much of the power (and also the complexity) of the Bluetooth protocols.

These profiles are the primary entry into the stack for an application. Essentially, they define the set of services that are available from a connection. Currently there are a total of 28 different profiles defined or in the process of being defined, as well as four higher-level protocols for specialized data and four more specialized transports for communications interfaces.

By the way, the documentation for these items is separate from that 1,200-page tome I mentioned earlier. Bluetooth definitely requires some heavy reading.

Good and bad news
The good news is that there are any number of choices for selection and optimization within the Bluetooth stack. The profiles are roughly equivalent to the numerous application protocols present in TCP/IP for things such as FTP, Dial-Up Networking (DUN), Serial Port Profile (SPP), etc. These allow a Bluetooth connection to morph into a large number of familiar forms.

That is, of course, part of the bad news as well. There will be a significant learning curve if you want to dig deeply into the Bluetooth protocol stack. It should be possible for most applications to use it relatively easily once it is set up, but that setup can be significant.

Most of the customization in a Bluetooth stack will probably take place in these profiles. It is quite possible to bypass them and communicate directly at lower layers.

This essentially allows you to create your own application profiles for specialized applications. This could be a very good choice for an application that wants to build a private dedicated network based on Bluetooth protocols. This allows the use of addressing and RF capabilities on top of the basic communications channel but strips away the other overhead.

Cellular data
Cellular data is becoming very interesting. There were very early uses for cellular communications to send data in the form of paging networks, and there were even some applications that used voice cellular to send modem signals, but in general these were either too unreliable, too slow, or too expensive (or maybe all three) for most mainstream applications.

More modern cellular transports are becoming available, however. GPRS/EDGE and CDMA 1xEVDO are being deployed now by the major carriers, and these have full packet-switched data communications capabilities at reasonable data rates. The carriers are even beginning to be more reasonable as far as charges for data communications. It might be a good idea to take another look at cellular data communications.

The alphabet soup of cellular acronyms is settling these days into two separate camps. First, there is the GSM camp, which is practically ubiquitous in Europe and also has a strong presence in the US. On this side the current state of the art is Enhanced Data rates for GSM Evolution (EDGE), which provides up to 400 Kbps capability.

This is being deployed by carriers such as AT&T, Cingular, and T-Mobile. The other side of the coin is based on the Qualcomm CDMA technology.

1xEVDO (Evolution Data Optimized), which promises up to 2.4Mbps, is being deployed in the U.S. primarily by Verizon Wireless.

The important thing to realize about the data rates described in the above paragraphs is the qualifier "up to." Wireless data rates in general should be taken with a grain of salt, and these in particular rate a whole shaker full of it. Most applications should count on at best half of that rated throughput for their applications.

One thing that is much improved in these networks is latency. Early data forms such as SMS and other packet technologies had tremendous variation in latencies, causing huge problems for some early attempts at applications. Current networks do a much better job at providing smoother packet flows. These issues have been problematic, but by far the biggest barrier to use of cellular for data transmission for embedded applications has been the need to qualify devices for transmission on the cellular networks.

Cellphones are very specialized devices that are built by a very few companies in the world, and generally those companies have not been interested in supporting devices that wanted to get on their airwaves. Once when we contacted Qualcomm for technical information to use their chipsets in an embedded application we got a call back within the hour from a lawyer threatening to sue us for patent infringement! This is not exactly what I would consider good customer support procedure.

Tweaking opportunities
Given this closed environment, what possible opportunities could exist for tweaking in cellular data? As it turns out, that problem is exactly the biggest opportunity. One answer is to use Bluetooth or even wired communications as a data path into the cellular networks.

The real advantage of this approach is that it insulates you from the changes that are taking place in the cellular networks. Rather than building GPRS/EDGE or 1xEVDO directly into your system, instead you build a Bluetooth link and use whatever network is available via an external cellular handset.

In fact, the handset itself can be worked around as well. A few companies now sell modules that are qualified for cellular communications and present serial or direct memory interfaces to allow easy integration into embedded systems.

The data transport itself is worth considering as well. There have been many applications using SMS as a data transport, but there are real limitations to that approach. SMS was originally included in cellular networks as a maintenance channel, and it was almost accidentally exposed as a service to the public to send short text messages. In Europe, many phone bills (especially for teenagers) have higher billing for SMS than they do for voice service.

The problem with using SMS for data applications is that it is a very limited packet service. The packet size is small (typically about 160 characters) and delivery is fairly uncertain. More modern TCP/IP-based systems are rapidly becoming available and are certainly the choice for new applications.

Wireless data is coming of age. The first stage of this was a hobbyist phase, where the tools were very immature and not suited for serious applications. This gave way to serious mass-market applications in the form of WLANs for laptop computers and cellular handsets, which built the network infrastructure.

The current phase of this evolution is the use of this infrastructure for any number of smart devices. None of these by themselves would justify the creation of the networks, but just like the Internet there are a huge number of applications that can use the infrastructure once it has been built.

About the author
Larry Mittag
is the lead consultant for Mittag Enterprises.

Article Comments - Fundamentals of the Bluetooth protoc...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top