Continuing our examination of the middleware protocols, we now visit those protocols intended to provide interoperability with IrDA applications. In this chapter we examine the protocols and conventions that together in the specification are termed "IrDA Interoperability." This term does not mean that devices with Bluetooth wireless communication can communicate directly with IrDA devices but rather it refers to protocols that enable common applications to use either form of wireless communication. The IrDA interoperability middleware includes protocols adopted from the Infrared Data Association (IrDA), namely IrOBEX (or briefly, just OBEX), its associated data object formats and the Infrared Mobile Communications (IrMC) method of synchronization. IrDA interoperability occupies fewer than 20 pages in version 1.0 of the core specification (volume 1), although over 100 pages are devoted to the IrDA-related profiles in volume 2 (this latter material is discussed in Chapter 14 of this book). As is the case with RFCOMM, the main reason that the IrDA interoperability protocols take up only a relatively few pages of the specification is that they call out existing standard protocols that are fully described in external documentation, in this case, specifications of the IrDA. IrDA application interoperability is a fundamental design principle for Bluetooth wireless communication, and thus the IrDA interoperability middleware is a key element of the protocol stack. These protocol layers are the basis for several profiles which are likely to become some of the most commonly implemented and widely deployed scenarios on devices that employ the Bluetooth technology. This chapter examines not only the IrDA interoperability information in the specification (as usual, attempting to reveal the rationale for these protocols) but also the similarities and differences between IrDA and Bluetooth wireless communication, since this latter topic is fundamental to the design basis for the IrDA interoperability solution adopted for the specification.
The IrDA interoperability protocols reside above other middleware protocols. In particular OBEX operates over RFCOMM in the standard case and also could operate over TCP/IP as an optional implementation.[1] Like RFCOMM and SDP, the OBEX session protocol uses a protocol data unit (PDU) structure, allowing the higher layers of the stack to work with logical data elements at a higher level of abstraction than that of the packet formats used by the transport protocols or even by RFCOMM. More importantly, though, OBEX primarily is intended to promote application interoperability with IrDA, so applications using this protocol with IrDA wireless communication can adapt easily to the use of Bluetooth links. Figure 9.1 depicts OBEX in the protocol stack. As shown in the figure, OBEX is used by higher layers of the stack, typically applications, and OBEX in turn uses other middleware protocols, namely RFCOMM (and optionally, within the constraints described above, also may use TCP/IP).
Before examining the specification in detail, we first look at the underlying technologies of IrDA and Bluetooth wireless communication. The objective, after all, for including IrDA protocols in the stack is to promote interoperability with IrDA applications (hence the "IrDA Interoperability" in the title of this chapter and in the specification). Here we must clearly state that this interoperability is at the application layer, not at the physical layer. IrDA interoperability does not imply that Bluetooth devices can communicate directly with IrDA devices. Instead it is intended to promote development of applications that can use either transport. uPrevious chapters have touched on the relationship of IrDA and Bluetooth wireless communication. Here we compare and contrast specific features of these technologies. Some excellent background reading on this topic can be found in [Suvak99], which was written by a SIG and IrDA participant.
IrDA is a specific use of infrared light as a communications medium; Bluetooth technology is a specific use of radio waves as a communications medium. Like the Bluetooth SIG, the Infrared Data Organization (IrDA) specifies hardware and software protocols for wireless communication intended to promote interoperable applications.
While both technologies are wireless, they use different parts of the electromagnetic spectrum with quite different signal propagation characteristics. Since infrared uses the nonvisible infrared light spectrum, IrDA communication is blocked by obstacles that block light (such as walls, doors, briefcases and people). The signal wavelength used with Bluetooth communication, at about 12.5 cm, is three orders of magnitude greater than that of IrDA. At this wavelength, 2.4 GHz RF communications can penetrate these sorts of obstacles. Recent advances in infrared technology have enabled more diffuse transmission patterns, although much of the IrDA equipment in use today uses a relatively narrowly focused beam, which usually requires that the two devices engaged in IrDA communication be aligned with (pointed at) each other. RF transmission patterns are generally spherical around the radio antenna, so any two devices within range can communicate with each other whether or not they are "pointed at" each other (in fact, the second device might not be visible at all to the user of the first device, as it could be in another room behind doors and walls or even on another floor of a building, for example).
The IrDA specification is more mature than the Bluetooth specification, having been available for several more years. IrDA technology was already widely deployed when the Bluetooth specification was first released. Thus IrDA has already undergone several phases of enhancement that Bluetooth wireless technology might undergo in the future. Among these is some improvement in communication speed. The initial IrDA data rate of 115 Kbps has now been enhanced to 1 Mbps, which is comparable to that of the first Bluetooth radios. Today IrDA can achieve data rates of up to 4 Mbps, with even higher rates already specified. While Bluetooth RF communication has the potential for similar increased data rates (and the SIG is investigating these possibilities; see Chapter 16 for more information), it is likely to lag the IrDA speeds for at least several years.
The effective range for Bluetooth wireless communication is about 10 meters using the standard 0 dBm radio. With optional power amplification of up to 20 dBm, range on the order of 100 meters can be achieved. IrDA range is about 1 meter and, as noted above, generally requires a line of sight to establish a connection.
Bluetooth wireless technology is designed for very low power consumption, and as compared to other RF technologies it consumes very little power. IrDA communication, however, consumes even significantly less power than Bluetooth technology, since far less power is required for infrared transceivers than for RF transceivers.
In terms of cost, IrDA hardware was significantly less expensive than Bluetooth radio modules at the time Bluetooth technology was introduced. This is partly due to the maturity and wide deployment of IrDA: the technology has been around long enough that several iterations of cost optimizations have occurred, and installed IrDA units number in the millions, so economies of scale resulting from high-volume production have been realized. Bluetooth modules in the year 2000 had not realized either of these forms of cost reduction; even so, it is expected that Bluetooth hardware is likely to remain more expensive than IrDA hardware[2] owing to the complexity of the underlying technology, although the cost difference probably will narrow over time.
Table 9.1 summarizes these feature comparisons of IrDA and Bluetooth wireless communication. The table reflects the state of these technologies in the year 2000 and reflects consensus forecasts in the industry. The table is intended to be illustrative rather than authoritative; certain parameters will vary from implementation to implementation.
Table 9.1. Illustrative feature comparison of IrDA and Bluetooth wireless communication. Estimates as of 2000; some values are implementation dependent.
| Feature | IrDA technology | Bluetooth technology |
|---|---|---|
| Connection establishment | Line of sight | Penetrates obstacles |
| Transmission pattern | Relatively narrow conical | Relatively spherical |
| Data rate | 4 Mbps | 1 Mbps |
| Range | 1 meter | 10–100 meters |
| Power consumption | 10 mW (nominal) | 100 mW (estimated nominal; product-dependent) |
| Transceiver module cost | < $1.00 | $5.00 (estimated, approximately 2003–2005) |
As explained in the specification and in the following sections, IrDA and Bluetooth wireless communication share similar application domains, even though the underlying technology used to achieve scenarios such as object exchange and synchronization is inherently different. Feature differences may cause one technology to be preferred over the other in certain environments and applications, although we believe that both have merit and both are likely to be deployed in pervasive computing devices in the foreseeable future. Thus the IrDA interoperability provisions of the specification can help to enable the best use of either or both technologies as the situation warrants.
One of the most common applications for IrDA technology is exchanging files and other objects. This includes exchanging electronic business cards between two devices as well as transferring files and other data objects between two devices, all in an ad hoc fashion and without wires. The devices commonly used in these scenarios—especially mobile phones, notebook computers and handheld computers, but also others[3]—are the same set of devices where Bluetooth technology is deployed or is expected to be deployed. Even though direct communication between an IrDA device and a Bluetooth device is not feasible, it seems clear that these same sorts of applications are quite relevant and useful in Bluetooth environments. In fact, profiles exist in the version 1.0 specification for both object push (which could be used for electronic business card exchange) and file transfer (which can include transferring several specific object types). An extended application of this sort of data exchange is synchronization, where the data is not only exchanged but is also replicated between the two devices. A profile exists for this usage case also, and it too is based upon the IrDA application and protocols. In volume 2 of the specification, all of the file transfer, object push and synchronization profiles are derivatives of the generic object exchange profile, and all of these are described in further detail in Chapter 14 of this book.
The rationale for IrDA interoperability in Bluetooth wireless communication is to enable the same applications to operate over both IrDA and Bluetooth links, and the most straightforward way to do this is to use the same session protocol in both environments. Since the IrDA protocols already existed and some were suitable for Bluetooth applications, the SIG chose to adopt OBEX and IrMC in the Bluetooth protocol stack in the same relative position as in the IrDA protocol stack. Unlike RFCOMM, the IrDA interoperability specification does not include any significant subsets, alterations, adaptations or clarifications of OBEX, although there are some specific considerations (such as calling out the specific OBEX version 1.2) noted for its use in the protocol stack. Much of the description in the specification echoes important elements of OBEX and describes precisely how OBEX is used over other middleware layers of the protocol stack.
The reuse of IrDA protocols and specifically OBEX was identified as the design direction of the SIG early in the specification's development. As with RFCOMM, work was underway on the use of OBEX and IrDA protocols and data formats at about the time the SIG was publicly announced. The synchronization usage case was already identified at that time, as were file transfer and data exchange applications (the latter scenarios at that time were part of the conference table usage case). In early 1999 the business card exchange scenario had led to the beginning of what is now the object push profile; file transfer and synchronization were well defined, and work on profiles for these usage models was also underway. It quickly became evident that a generic framework profile that applied to all IrDA interoperability usage cases (that is, all those profiles using OBEX) would be valuable, so the generic object exchange profile also was initiated.
Given the objective of interoperability between IrDA and Bluetooth applications, an initial goal of the SIG was to produce a specification that would allow a single application to operate seamlessly over both wireless transports. The SIG was (and is) motivated to reuse existing protocols where appropriate. These considerations led to the selection of OBEX as the point in the IrDA protocol stack that could be inserted into the corresponding point in the Bluetooth protocol stack to allow applications to deal with the same protocol (OBEX) in both environments. With study and discussion in the SIG it was determined that OBEX could operate both over RFCOMM, which was reasonably well defined by this time, and over TCP/IP (although the latter is enabled only in certain circumstances in version 1.0, as discussed below). Other transports for OBEX not directly applicable to the Bluetooth protocol stack include IrSock (infrared sockets), IRCOMM and Tiny TP (or TTP), some of which are mentioned in passing in the specification.
IrDA interoperability in general, and OBEX and IrMC in particular, are significant elements of the protocol stack, yet relatively few pages[4] are devoted to the topic in volume 1 of the version 1.0 specification. OBEX is the basis for several of the version 1.0 profiles and IrDA interoperability is an important objective and key value of the Bluetooth technology. The IrDA interoperability specification can be so compact because of the SIG's decision to adopt existing IrDA protocols that are fully specified by IrDA (the IrDA OBEX specification [IrDA99a] is about 85 pages long while the full IrMC specification [IrDA99b] is nearly 200 pages, although only a portion of this latter specification deals directly with IrMC synchronization).
While the specification discusses the use of OBEX over TCP/IP, it does not define how TCP/IP should operate natively over Bluetooth transports. The fact that OBEX can operate over TCP/IP will become more important in the future when the SIG defines general TCP/IP operation over Bluetooth links (as described in Chapter 16). Until such a definition exists, the fact that OBEX can operate over TCP/IP transports is not directly relevant for version 1.0 implementations.[5] Thus TCP/IP operation for OBEX is specified as optional.
The other Bluetooth protocol over which OBEX is designed to operate is RFCOMM. RFCOMM (detailed in the previous chapter) was designed specifically with OBEX in mind as one of the RFCOMM clients. Since OBEX over TCP/IP is defined only in the context of PPP for version 1.0, we focus here on its use over RFCOMM. The specification describes the requirements for the use of OBEX over RFCOMM. These are not new or unique requirements specific to Bluetooth environments; rather they define the boundaries within which a generic OBEX application should operate to ensure that it will work over RFCOMM and thus over Bluetooth transports. Among the considerations for OBEX over RFCOMM are:
Client and server functions: The specification indicates that both client and server functions must be supported by devices implementing the OBEX IrDA interoperability protocol. When one examines the IrDA interoperability profiles (see Chapter 14), it becomes evident that while it is technically possible for a device to support only a client or only a server role, it is really useful only when a device can support both roles. Even object push, which is largely a one-way data transfer, still requires both a client role (in this case the client needs to push the object) and a server role (in this case the server needs to pull the object). This apparent dichotomy is explained in Chapter 14.
RFCOMM multiplexing: All OBEX transactions must use a separate RFCOMM server channel (as described in the previous chapter, only one RFCOMM connection is permitted between two devices); thus, multiple clients of RFCOMM must use its protocol multiplexing feature. The OBEX server must open a separate RFCOMM channel connection with a client. Similarly the RFCOMM connection needs to be terminated when the OBEX session that uses it is terminated. The specification also describes how to parse the stream-oriented communications that occur over RFCOMM to delimit the OBEX packet structures contained therein.
SDP Support: OBEX applications in Bluetooth environments need to be able to make use of SDP. OBEX clients need to obtain the relevant information about the OBEX service from its service record in the OBEX server. OBEX servers need to populate the service record with information such as the appropriate RFCOMM server channel to use. As described in the previous chapter, this SDP application enablement might be obtained through the use of common SDP application services; these need not be unique to OBEX applications.
OBEX provides a session protocol for transactions between two devices. The IrDA defines both connection-oriented and connectionless sessions; the Bluetooth specification calls for use of only the connection-oriented sessions, since this is what best fits Bluetooth environments. Like SDP, OBEX transactions consist of a request PDU issued by the client followed by a response PDU issued by the server. With OBEX, the client role normally is assumed by the device that initiates the transaction, while the responding device becomes the server. Also similar to SDP, the OBEX PDUs consist of a header, a size indicator and the arguments and parameters associated with the particular transaction. Fundamentally, OBEX is a simple protocol, with the main operations being connect and disconnect to initialize and terminate sessions, along with get and put operations to exchange data objects within an existing session. These operations are described in the Bluetooth specification and detailed in the IrOBEX specification.
In addition to a session protocol, OBEX also serves as an object transport for the data that can be exchanged in OBEX sessions. To support the IrDA interoperability profiles, the specification calls out particular object formats as follows:
vCard: format managed by the Internet Mail Consortium [IMC96a] for representing electronic business cards.
vCalendar: format managed by the Internet Mail Consortium [IMC96b] for representing electronic calendar and schedule entries.
vMessage: format defined by IrMC [IrDA99b] that represents electronic messages and electronic mail.
vNote: format defined by IrMC [IrDA99b] that represents short electronic notes.
Volume 2 of the specification calls out each specific object format as it applies to the object push, file transfer and synchronization profiles. Some of these profiles allow for different versions of the object types noted above; some also allow for other generic object types to be used with OBEX.
In addition to transferring data objects over OBEX, it is also quite useful to synchronize these same objects. Synchronization, generally, is the process of comparing two sets of data and then updating those data sets so that they exactly reflect (are synchronized with) each other at the point in time that the synchronization is performed. There are variations on the synchronization process, such as one-way synchronization where a "slave" data set is always updated to match a "master" data set, or partial synchronization where only a subset of the data is synchronized, but in general the idea is to merge the changes made in two (or even more) data sets into each other so that the data sets become replicas of each other (until additional changes are made to them). Synchronization allows data (perhaps calendar entries, address books or e-mail) to be manipulated at various times and places and then be replicated against some other related data set so that the updates from the data manipulation can be applied. Applications for synchronization include synchronizing address books to incorporate new, changed or deleted entries; synchronizing calendar entries to incorporate new and changed schedule items; and replicating e-mail to send and receive new notes and messages and incorporate saved or deleted messages. Synchronization can be especially useful when these types of data are kept on more than one device. Address books, calendars and e-mail can be replicated among mobile phones, handheld computers, notebook computers and network repositories of data so that no matter which device is used, the data on that device can be current and updates to these data can be reflected on the other devices through synchronization.
Note that the devices mentioned above are some of the devices most likely to employ Bluetooth wireless communication. Thus it seems that synchronization is a natural usage case in Bluetooth environments. Note further that the types of data mentioned above as being common candidates for synchronization (calendar, e-mail and contact information) are the same data types defined in the profiles for object transfer over OBEX. Thus it seems evident that it ought to be valuable and feasible to employ OBEX-based synchronization in the specification, and indeed this is precisely what the SIG has done. Just as with object transfer, the SIG has chosen to adopt the method defined by the IrDA, called IrMC synchronization. IrMC synchronization builds upon the OBEX session protocol and certain object formats (including some object formats defined by IrMC itself) to specify a method of synchronizing these objects. As with OBEX, the specification incorporates IrMC synchronization as a way to enable IrDA application interoperability.
The core specification (volume 1) includes very little information about synchronization per se, focusing instead on the use of OBEX in Bluetooth wireless communication. It does, however, briefly describe Bluetooth synchronization when discussing the synchronization profile, which is where the details can be found. Essentially IrMC provides a framework for OBEX-based exchange of data; given this capability to exchange data formats including those noted above, additional logic can be applied to perform differencing and selective object transfer, thus accomplishing synchronization using the IrMC framework within OBEX sessions. Chapter 14 more fully explores Bluetooth synchronization.
The IrDA interoperability information in the core specification (volume 1) includes a description of the related profiles found in volume 2 of the specification. In fact, since IrDA interoperability is really about application interoperability, there is a larger amount of information (over 100 pages) on this topic in the profiles than in the core specification. Recall that IrDA interoperability just makes reference to existing IrDA specifications and describes how to use these standards in Bluetooth environments.
The reuse of IrDA protocols, along with the fact that these protocols operate over RFCOMM (a serial port abstraction), is intended to facilitate the use of existing IrDA applications in Bluetooth environments. IrDA applications are familiar with the use of serial port communications and are likely to have support for OBEX protocols. By accommodating these IrDA interoperability layers in the Bluetooth stack, the SIG has paved the way for applications that can operate with both IrDA and Bluetooth wireless communication.
[1] While TCP/IP operation for IrOBEX is described in the Bluetooth specification (volume 1) in the same level of detail as is RFCOMM operation for IrOBEX, there is no SIG-specified end-to-end TCP/IP solution for version 1.0, since the specification does not address the general use of TCP/IP over Bluetooth transport protocols. Thus, even though IrOBEX could work over TCP/IP, and the IrDA Interoperability chapter of the specification describes how to do this, IrOBEX is assumed to operate over RFCOMM throughout volume 2 of the specification because TCP/IP is not fully specified in the version 1.0 Bluetooth protocol stack. As noted elsewhere, though, TCP/IP can operate over PPP links, and general IP networking solutions are in progress within the SIG.
[2] Bluetooth radio module costs in the 2003–2005 time frame are variously estimated to approach $5 U.S.; IrDA solutions are already well below this figure.
[3] Perhaps including digital cameras and computer peripherals such as printers.
[4] At fewer than 20 pages, the IrDA Interoperability portion of the specification is easy to read from beginning to end, yet it is a fairly complete description of how IrDA protocols are used in the Bluetooth stack.
[5] Which is not to say that such a stack could not be implemented; in fact, it could. But like all other implementations not based upon profiles, the risk of noninteroperability exists. Because TCP/IP is such an important protocol, it is safe to assume that TCP/IP over Bluetooth links eventually will be solved (this is being pursued by the SIG), and thus it is good to know that OBEX over TCP/IP is already enabled.