Making the Bluetooth Application Connection Understanding a system's relationships to complimentary devices is key to developing great Bluetooth applications. Pop quiz! In the fast-paced world of high technology, the term Bluetooth refers to which of the following: A) a wireless replacement for cable, B) a new market in which to make millions, C) a short-range communication system, or D) a very popular buzzword. The answer would appear to be all of the above.
The Bluetooth specification addresses the wireless transport of data and voice over radio, and defines a complete system consisting of radio, protocol, and even application profiles. Profiles cover the way in which both radio and protocol components are used in facilitating the application and are carefully defined by the specification.
The intention behind exerting this level of control by the Bluetooth Special Interest Group is to ensure that interoperability exists between Bluetooth products that originate from different vendors.
Without first understanding how a Bluetooth system works, developers designing Bluetooth solutions will certainly encounter difficulties during implementation. Designers need a practical view of how Bluetooth systems work, pulling together many diverse components that make up the specification.
Network basics
Bluetooth applications can only be supported within the context of the personal area network (PAN) which is markedly different from the 802.11 wireless LAN. Comparisons have been made between the two in the areas of radio power required, cost of implementation, and data rates supported. The main (and often ignored) difference lies in the variety of unique applications that are supported by Bluetooth as opposed to applications supported by 802.11. Further differentiation comes when considering the convenience of having access to an ever-changing array of applications that can be offered to highly mobile users of Bluetooth technology.
In a typical Bluetooth network, or piconet, RF connections are established between master A, which controls the network, and up to a maximum of seven active slave devices that communicate with the master when permitted (see Figure 1). Slaves do not communicate with one another directly.
As shown, master #7 falls outside of the 10-meter range covered by the LAN access point (LAP). Upon its entry into the serviced area, the PDA will establish a connection to the LAP and will eventually change roles from master to slave under command from the LAP (assuming the identity of the seventh active slave device). At this point, it will act as a client as it begins to take advantage of the services offered by the LAP.
The procedure is deceptively simple in appearance. In reality, the process requires multiple steps that are planned for and designed into the application software.
Bluetooth system developers should keep in mind a few items that can affect system performance such as RF link budget and bandwidth sharing. Bluetooth devices are typically specified to work within a 10-m radius - a direct result of having to preserve battery life. It is permitted, however, to design Bluetooth units that transmit at higher power levels, extending the coverage area to a radius of 100 m. Stationary units can take advantage of an AC power source, so battery life is no longer an issue. The implication of mixing a low-power unit such as a PDA and a unit supporting greater transmit power (maybe a LAP) results in an unbalanced communication link in terms of RF power. The distance between units must be 10 m or less for a radio link to be established in this case.
The maximum data rate that can be supported by the radio link is 723.2 kbps from the master to slave, with an associated 57.6 kbps in the reverse direction from slave to master. Note that this bandwidth is shared by all active slaves in the piconet. Another data link configuration (out of several different configurations) supports a balanced data flow which can be achieved in both directions at 433.9 kbps. Data rates are strictly determined by the host controller (radio hardware), yet are influenced to some degree by the upper layers of the Bluetooth stack and the application code.
Stack functions defined
Network connections are facilitated at different levels by protocol with a basic stack (see Figure 2). Baseband and radio hardware serve to control frequency hopping and time division duplex operation as implemented to support the communication channel. Although fascinating, this element of operation does not have to be well understood by the application designer since functions at this level remain transparent to the developer.
Link management protocol (LMP) is next in the protocol chain. It is responsible for many functions including authentication, enabling encryption, and maintaining and controlling the radio link. These functions are managed by the application software.
The host controller interface for (HCI) is an interface that is specified allowing the host controller (radio hardware) to communicate with the upper portion of the Bluetooth protocol stack that typically runs on another processor. This point becomes important when developing a Bluetooth solution since this interface permits the integration of radio hardware with the upper stack and application software across a hardware boundary, which is generally based on a universal asynchronous receiver transmitter (UART) or USB.
Logical link control and adaptation protocol (L2CAP) operates as a data link level protocol layer capable of establishing point-to-multipoint connections (one master with multiple slave devices), segmenting and re-assembling data packets, and aggregating or mixing upper layer protocols (such as RFCOMM and service discovery protocol [SDP]) together, and directing incoming data to the appropriate protocol.
RFCOMM is a serial port interface into the stack and is capable of supporting up to 60 different connections (such as COM1 and COM2 in the DOS world). SDP can act as either client or server.
As a client, it asks for information on services provided by another Bluetooth node. As a server, it provides critical information related to services that are active on the Bluetooth device.
Product assembly
Additional modules that have been labeled as management entity, security manager, and event manager are shown to represent the functions that are necessary in controlling operations of the Bluetooth device. The management entity provides an interface to the application developer allowing them to find other Bluetooth nodes within range as well as establish an RF connection to these nodes.
The security manager authenticates other devices that want to establish a connection in an effort to use services offered. It also enables an encryption mode that protects data being transmitted and received across the very public RF link. The event manager is a critical piece of the stack as it provides all interfaces necessary in integrating the stack into an operating system (OS), which is the first step in implementing any solution (See Figure 2).
It is possible to adversely affect stack operation (and mandatory product certification by the Bluetooth Qualification Board) if certain precautions are ignored. Stack re-entrancy, memory management, and peripheral integration software that may absorb an inordinate amount of processor time could become pressing issues for the designer. Such items are dependent upon the protocol stack software used since a number of different vendors offer Bluetooth solutions in this regard.
Stack processing must be invoked on a regular basis to ensure that it responds in a timely fashion to incoming data as well as to sending data originating from a native application. Because embedded hardware solutions are unique, developing your own hardware driver is required to support communication between the host controller or radio hardware and the host or control processor.
The interface between host and host controller makes the HCI necessary to ensure compatibility between components offered by different vendors providing protocol and radio hardware components. Most radio hardware provided by several vendors supports either a UART or a USB connection. Transport driver source code is usually provided by protocol vendors for unlimited use by the designer in developing this interface to the radio. Modification of the source code is usually required, given the different hardware platforms that are used by product developers.
Application development
Figure 2 shows two distinct application modules: one module (connection management) is responsible for managing connections to other Bluetooth devices. The other module actually implements the application. In this case, the application is a LAN access point and includes PPP and an appropriate protocol interface to the LAN, which is not shown.
The single most important element in developing applications is in knowing how the Bluetooth system works using protocol components making up the stack. There are potentially five steps to establishing a connection between devices before using the application, and these steps are common regardless of the profile being developed:
- Device discovery (or inquiry): determining the addresses of other Bluetooth devices in the vicinity as well as their capability using the class of device (CoD) information;
- Name discovery: optionally determine the proper name of a discovered node by connecting to this node and requesting this information;
- Service discovery: getting information about applications supported on a device as well as information necessary in connecting to the application;
- Security: passing authentication, authorization procedures and implementing encryption if required;
- Application connection: invoking the application using parameters provided through the service discovery process.
The PDA in Figure 1 must first discover other Bluetooth devices and does so by repetitively transmitting INQUIRY packets. Other devices wishing to reveal their presence within a 10-meter service area respond with messages containing their unique address, as well as information indicating service supported and attributes of the service. An example of this additional CoD information is provided in Table 1.
The next step is optional. If the service revealed to the PDA during its discovery process is acceptable (LAN access, in this case), the PDA can determine the proper name of the remote device. It does so by connecting to the LAP, requesting the name, then disconnecting. The PDA can present this name to the user, and, if recognized, procedures to establish a connection can begin.
Service discovery is the next step the PDA must take. Requests are made to the LAP to reveal further information about the services offered. Impor-tant information presented to the PDA includes not only the services offered but also the way that the PDA must establish a client connection to the LAP, which can change dynamically.
Two pieces of information are of interest here: the serial port number to connect to at the RFCOMM module level and LAN loading statistics. If the LAN is heavily loaded and operating at near full capacity, the PDA may not want to proceed with the service offered since it may be painfully slow.
Since Bluetooth is a public network, security measures are often used to protect nodes from unauthorized access. Three security modes are available: no security, application security, and radio link security. With no security, any device is allowed to access the LAP. This is disallowed according to the specification. With radio link security specified at the LAP, security procedures are invoked when another device such as the PDA attempts to establish a radio connection.
When using mode 2 security, the LAN access point starts the authentication process (or pairing) once a request has been received to establish a peer-to-peer connection at either the L2CAP or RFCOMM layers as shown in Figure 3. In this example, RFCOMM will serve as the trigger point in invoking security measures instigated by the LAP. Once triggered, the LAP uses the unique address of the PDA that was provided when an RF connection was established. Next, the LAP gets a personal identification number (PIN) either manually entered by the user or stored in memory. The LAP then generates a random number and sends this number to the PDA. Both sides generate a number (link key) using the PIN, PDA address, and random number. The PDA sends this number back to the LAP and this number is compared with the number generated on that side of the connection. Finally, if they match, the PDA is authenticated.
Figure 4 illustrates what happens at the application level to support mode 2 security. Before further examining this example, there are two other elements associated with security that must be described: authorization and encryption. Authorization is the act of asking the user if a connection is allowed, generally through a user interface. If the answer is yes, the connection is allowed. (Encryption, when invoked, is applied to the transmitted and received data between devices protecting it from eavesdroppers that may intercept this information).
The dirty (almost) dozen
Returning to the example of a LAP application that implements security, there are 11 steps taken. The PDA attempts to access the application and does so by sending a connection request to establish an L2CAP connection. Once complete, an RFCOMM connection is requested, the security manager is alerted to this request and looks in the service database, which indicates authorization and authentication required.
Next, the security manager examines the device database to see if this Bluetooth device has ever passed authentication for this service in the past. If the device has, it could already have a link key that could be used, and authentication would proceed transparently - these units would be bonded.
Assuming the PDA is not a past user, the security manager instructs the host controller to begin authentication. The radio hardware requests a PIN from the security manager, which in turn invokes the connection management application to get a PIN number from the user (or from memory). This PIN is returned to the security manager, which in turn provides this number to the host controller. Authentication successfully completes (assuming that the PDA uses the same PIN number). The device information is entered into the device database for future reference. The security manager then begins the authorization process: it asks the user (or looks at memory) if it should allow the PDA to connect. If the answer is yes, this information is stored in the device database and encryption is turned on. The RFCOMM connection can then be established.
The PPP session can now proceed as it normally would; this is defined in the LAN access profile description in the Bluetooth Specification V1.0B. The application, access to the LAN, and subsequent server node can now be started and used.
Application initialization
While connection management can be complex, it shouldn't be too painful for a comm designer, armed with a systems view, to understand. Before attempting to manage any radio connection, the software must first configure the embedded system by performing a few specific tasks.
First, it must assign a name to the product which is linked to the hardware address of the radio unit (such as Hardware_Design). Also, it must define the CoD parameter - this can be determined by the end user for the purposes of uniquely identifying the product.
The software must also initialize the SDP database with a service record (or records) indicating the type of application supported by the product as well as associated attributes that further characterize the application (as an example, port 4 on RFCOMM is to be used to support connections to the LAN).
As part of this process the software must initialize the service database with information relating to security modes required for service access with the Bluetooth services offered by the product (see Figure 4). All applications must then be registered with the Bluetooth stack, thereby allowing the stack to inform the applications that incoming data is ready for further processing.
If a data port at the RFCOMM level is registered and ready to accept connections from remote applications, or data from a remote Bluetooth device is available for processing, the software should then configure the radio hardware to occasionally listen for other Bluetooth devices that are in range and that transmit an INQUIRY message.
The LAN access point is, quite obviously, a server. It offers services to other Bluetooth devices and as such must be prepared to respond in a number of different ways in order to provide remote Bluetooth devices with mandatory information permitting it to use the service.
Developing applications using Bluetooth technology requires the development of support software responsible for OS integration, hardware integration, RF connection management, and security measures. When this is completed, the engineer can focus on designing and implementing applications successfully.
Intense knowledge of radio operation, or even Bluetooth protocol stack operation, is unnecessary to implement successful software. Knowledge regarding how the system is to operate with complimentary devices, however, is critical.
We have focused on the development of the underlying software simply because these are the types of questions that are being asked by many application developers wanting to implement solutions quickly. Being interoperable with other devices in the marketplace will be the true measure against which Bluetooth will be judged a success.
Brian Senese is currently an applications engineer for Extended Systems. He has also worked as an engineer developing wireless data solutions for companies such as Nortel, Lucent, Uniden, ADC Telecommunications, and Hughes Networks Systems. He holds a Masters Degree from the University of Western Ontario and can be reached at brianse@extendsys.com
