Bluetooth and wirless hacking

The Bluetooth Specification: A Technical Overview

                   Michael Zenke

Introduction

The Bluetooth wireless technology specification, due to the overwhelming support that it has been given by corporate interests, may be one of the defining technologies of the early 21st century. As such, understanding that specification and possible applications of that specification should be priorities for persons who wish to understand the advance of technology. However, the newest Bluetooth specification, at nearly 1500 pages, is a daunting read for even those whose occupation depends on knowing the spec by heart. For those of us who might have a more casual interest in Bluetooth, that kind of time commitment is unacceptable. However, those with casual interest in the technical side of Bluetooth may also be daunted. The 1500 page specification holds no interest, but at the same time a 4 page marketing paper designed to catch the eye of a CIO may not fulfill the needs of such a reader either.

The purpose of this paper is to fulfill the needs of a reader with casual interest in the Bluetooth specification in a relatively concise format. Topics covered in this paper will include the Bluetooth SIG (Special Interest Group) and a brief history of the project, the basics of the Bluetooth technology, Bluetooth Usage Models , the Bluetooth Protocols, and Bluetooth Profiles.

Assumptions

This paper assumes the reader has at least some knowledge of what the Bluetooth Specification is, has had exposure to computing and wireless technology, and has at least some knowledge of the protocols that underlay the internet. Knowing that Bluetooth is an approach to wireless technology will essentially be enough, but at least having read about the OSI Seven Layer Model will make the Protocol section of this paper more understandable. Having working knowledge of RF wireless communication will not be necessary.

Supplemental Reading

·        Bluetooth Basics: http://www.bluetoothweb.org/

·        The OSI Seven Layer Model : http://www.freesoft.org/CIE/Topics/15.htm/

·        Bluetooth SIG Site: http://www.bluetooth.org/

·        Bluetooth General Info Site: http://www.bluetooth.com/

The Bluetooth SIG and Origins

            Bluetooth as a technology originated with the Swedish telecommunications company, Ericsson. In 1994, Ericsson started an (at that time) internal project with the stated goal of producing a cheap, effective, low powered radio system to eliminate the need for wires between mobile phones and their accessories. As the project was developed, it was realized that not only could wires be replaced in that scenario, but in many more as well.

Realizing that proprietary technologies rarely if ever are adopted by consumers in large numbers, and not wanting this idea to fail, Ericsson proposed the creation of a multinational Special Interest Group to develop a specification for the technology. The name "Bluetooth" was chosen for the project, because of a Swedish myth involving a Scandinavian kind named Harald Blåtand. The legend held that Kind Harald united Norway and Denmark, and brought Christianity to Scandinavia. Bluetooth is the best translation available of his last name, given to him (according to folklore) due to his propensity for blue-stained teeth as a result of eating blueberries. Thus, the Bluetooth promoter companies would be brought together under the name of a country unifying King. These first promoter companies were Ericsson, IBM, Nokia, Intel, and Toshiba. Since 1998, the year of the SIGs inception, hundreds of adopter groups have joined up with the SIG, representing companies from such diverse sectors as automobile manufacturing, agricultural development, and genetic engineering.

A year and a half of meetings and conferences resulted in the first draft of the Bluetooth specification, nearly 1500 pages in length. This specification has had several addenda and revisions tacked onto it as the adopter groups have had commentary on the final product. The Bluetooth SIG keeps the specification up to date by incorporating worthy commentary and ideas as they are developed. As new applications of Bluetooth technology are developed, they keep consumers apprised of new opportunities, and adopter groups apprised of new implementations. As Bluetooth usage begins to become commonplace, the SIG will continue to act as decision making body for directions in which the technology will go.

Bluetooth Basics

Bluetooth is, at it's core, an approach to removing the need for physical wires in a multitude of situations. The specification removes this need through the use of inexpensive, low power radio communication. Most radio communications are done over a specific spectrum. The Federal Communications Commission assigns frequencies for designated uses. For example, 151.625 mhz is a communications band given over to the use of itinerate workers and events, like sports teams and trade shows. Bluetooth removes the need for having a specific band assigned to it by using every frequency band at extremely low power. The original spec, in fact, calls for Bluetooth communications to reach only as far as 10 meters. More recent specs allow for broadcasts of up to 100 meters under certain circumstances.

This low-power, frequency independent radio communication system was intended to be as flexible as possible. Removing wires from so many different situations meant that Bluetooth technology would be put to use in a multitude of ways. Additionally, this sort of technology would open the door for many completely new technologies. The ways in which the Bluetooth SIG ensured the technology's flexibility are threefold: The Master-Slave Relationship, Energy Use Decisions, and Fluid Topology.

The Master Slave Relationship is the term used to describe the two different roles that Bluetooth nodes can play. Any Bluetooth node can be either a Master or a Slave. Functionality for both should be built into each node, according to the spec. The "Master" status simply means that, within a currently active Bluetooth network, the node decides which frequency the nodes of the currently active network will broadcast on. Master status is usually conferred to whichever node starts communication with the other Bluetooth nodes in the area. The broadcast frequency changes every few seconds (as discussed above), according to the Master node's internal clock, and it is the Master's job to inform each Slave node of the new frequency. Slave nodes communicate at regular intervals with the Master node, again based on the Master node's internal clock. As far as the user is concerned, this Master - Slave business might as well not even be happening, as it is totally transparent which node is the controlling unit in a Bluetooth network (or piconet, a term I will use from now on for brevity). The point of the Master - Slave relationship is for quick and dirty networks to form whenever there is a need, a concept discussed further below. Another point of the Master - Slave relationship is power consumption.

The lifespan of any type of technology intended to replace wires should be quite long, as wires themselves never run out of power. Convincing consumers to replace their wires could not be feasibly replaced by a technology which would need to have fresh batteries every five minutes. Thus, another aspect of Bluetooth's flexibility is the creative ways in which it uses available power. A master can communicate with up to 7 active slaves at a time, and can be in communication with up to 255 parked slaves. These terms, active and parked, are modes in which Bluetooth nodes behave differently. Active Slaves always listen for packets from the Master node, responding to those packets when the are addressed to them. Parked slaves, on the other hand, are in a low power mode. They synchronize their clocks every few cycles with the master node, but otherwise are not listening for communications from the Master. In order to bring a parked Slave up into active mode, the Master much make a specific call to the parked Slave, forcing it into an active state. In this way, the Master can orchestrate the Slaves it oversees, dropping and lowering slaves from active into parked modes and vice versa as the needs of the piconet change. In this way, only members of the piconet which need to be communicating for a period of time need expend energy listening to communications. This fluidity of organization is one of the great strengths of Bluetooth, and the topology of the piconets is an extension of that fluidity.

Traditional networks, while becoming more easy to set up every year, are still generally projects requiring some amount of effort. Aside from the wiring involved, which was the primary purpose of the technology, Bluetooth makes networking much more simple because of its ability to create networks on the fly. Piconets, or Personal Area Networks, are created on the fly when Bluetooth devices come within range of each other. A piconet consists of a single Master, and the active and parked Slaves associated with it. Each node in the network communicates on a peer to peer basis, exchanging information as needed. This seamless networking is now the main thrust of Bluetooth. In removing wires from devices, simple local networks were created. Instead of a wire from your computer to your printer, your scanner, your keyboard, your mouse, your joystick, your network, and your speakers, there is a Master (your PC), and seven active Slaves. Additionally, a node need not be only one piconet. That printer and scanner, for example, could be nodes on the piconets of all of the employees around you. When one or more piconets overlap, an entity known as a scatternet is created. These scatternets allow for data and device sharing, as each node synchronizes with several Masters, possibly even taking on the role of Master on one piconet and Slave on another. This extraordinary flexibility of topology allows for many extremely varied usage models.

Bluetooth Usage Models

            The specification details eight distinct usage models. As more become obvious to the members of the Bluetooth SIG, they will be added to the spec. The current usage models detailed in the specification are:

• The Cordless Computer
• The Ultimate Headset
• The Three-in-One Phone
• The Interactive Conference (File Transfer)
• The Internet Bridge
• The Speaking Laptop
• The Automatic Synchronizer
• The Instant Postcard

The Cordless Computer -

            This usage model is the piconet described above, wherein the different nodes are the devices that could potentially be used by a laptop or desktop. The Bluetooth radio technology simply removes the need for a serpent's nest of wires to allow communication between the devices.

The Ultimate Headset -

            With a Bluetooth radio built into a headset, one device could become a person's standard interaction with anything which produces sound. A headset connecting (via Bluetooth) to a mobile phone, or even a cordless phone, would allow an individual true freedom of movement while communicating. A Bluetooth enabled portable CD player would allow for unobtrusive music listening. In the "Cordless Computer" usage model, the headset could take the place of a pair of speakers. The Headset is a great example of the flexibility one piece of technology can gain when added to a piconet.

The Three-in-One Phone -

            Many people use several different phones throughout the day. One at home, a mobile one while on the move, and one at the office. A Bluetooth phone could allow an individual to carry just one phone, and have it operate in several different capacities. At home and in the office, the phone would latch onto a piconet with a VAP, or Voice Access Point. When someone calls your work number, or home number, and your phone is currently on the local piconet, it rings. When you are away from your home or office, the phone would simply act as a cell phone. (Possibly hopping from phone company piconet to piconet.) Finally, if two Bluetooth phones were close enough to establish a piconet, you could talk directly phone to phone, in a walkie talkie style. This last usage would especially be useful in support of the "Ultimate Headset" model in situations like a theater's crew, or a fair's support staff. Again, like the "Ultimate Headset" model, Bluetooth's strength is in giving already useful technologies new uses.

The Interactive Conference (File Transfer) -

            Already a staple of users of Personal Digital Assistants (PDAs), quick and dirty file transfers are an extremely popular use of "cordless" technology among businesspeople. With Bluetooth enabled devices talking back and forth to each other as a matter of course, every person you shake hands with at a conference may be depositing their business card into your PDA, just as you do the same to theirs, whether or not you're aware of it. Simple terminals in front of everyone in a conference room could have access to a group of files. As new editions of the documents are created, they could be passed around to everyone's terminals.

The Internet Bridge -

            Possibly one of the most useful of the models, the Internet Bridge would allow devices with the ability to surf the web to get access to an Internet Access Point. This is very similar to the "Three-In-One Phone" concept of a Voice Access Point. Your laptop, PDA, or phone could simply latch onto a piconet with an IAP as one of the nodes and use communication with that node to gain access to the Internet. This IAP could be either a mobile phone or modem of some sort, or a connection to a LAN. A node connecting to a phone or modem could then dial out to the internet via the dialing device. A node connected physically (or not, in the case of a traditional wireless network) to a LAN could offer the LAN's internet connection to any node connecting to the Bridge via Bluetooth. This application of piconets increases not only the functionality of Bluetooth nodes, but the flexibility of location for the users as well.

The Speaking Laptop -

            As with many aspects of technology today, this model seeks to obscure from the users of the technology the actual nitty gritty aspects of the devices they are using. In this model, this extends even to what you're talking on. Since, as has been shown in previous models, which node uses the different kinds of information available to the piconet is unimportant, a person seeking to contact another person could call a phone number, and reach that person - at their computer. This is essentially a combination of the "Ultimate Headset" and "Three-In-One" phone models.

The Automatic Synchronizer -

            As anyone who makes daily use of a PDA could tell you, using one can be a very worthwhile experience. However, those same people would also likely fill your ear with the troubles of keeping all the data they have about their lives current. Someone assigns you a task via the corporate calendar, which then has to be propagated to your computer, which then has to be manually added to your PDA, which has to be synced with your computer in order to back up it's data. The ease of unobtrusively distributing information over piconets would make this ordeal a thing of the past. As in the "Interactive Conference" model, simply walking into a room could cause information you have somewhere on your person (on a PDA, phone, or laptop) to be synced with information somewhere in the room. An update to a meeting could be bounced through the piconets of a building, updating everyone's information. If someone is not in the building at the time, perhaps a Telecommunications piconet would shoot that information out to concerned individuals outside the building. Or, perhaps that information is given to a Gatekeeper piconet at the front door, which updates devices as they pass through the piconet.

The Instant Postcard -

            This model extends some of the previous models to the utmost. The concept detailed by the spec was that a digital camera could, as opposed to saving an image to local media, the camera would just shoot that image to a piconet, where it would be saved to a node with storage media. Or, for the actual postcard part of the model, the image could be bounced to an IAP on the piconet (or extended scatternet), which would shoot the image to an email account, so that your family could see what you were up to.

            These usage models were created to give interested parties bases from which to create other usage models, protocols, applications, and devices. Below we will see how the disparate protocols that make up Bluetooth facilitate these usage models.

Bluetooth Protocols

          The actual protocols which make up Bluetooth Technology are the bulk of the information detailed in the specification. To go into any level of detail on the protocols themselves would take many pages. Thus, this paper will detail the different levels of the protocols, separate out the protocols, and give a brief description of what each one accomplishes. The Bluetooth Protocol Stack consists of the Transport Protocols Group, the Middleware Protocols Group, and the Application Group.

The Transport Protocol Group consists of the lowest level, most machine oriented protocols. These protocols are the backbone on which Bluetooth is built. They are (from lowest to highest) : Baseband and Radio Protocols, the Link Manager Protocol, and the L2CAP Layer. Within the Transport Group also exists the HCI layer, a module for ease of communication between the Transport layer and higher layers.

The Baseband and Radio protocols do the actual work of initializing the connections between the different Bluetooth devices. It is these protocols which facilitate the frequency hopping that makes Bluetooth possible. The Baseband layer is the piece of the protocol stack that facilitates the master/slave relationship between the Bluetooth nodes.

The Link Manager Protocol is the language which the link managers in each Bluetooth device use to speak to one another. The Link Managers set up secure transmissions using what is called a challenge-response system. This encryption and trust allows piconets to form. The Link Manager also oversees prioritizing of bandwidth for the disparate demands of asynchronous data traffic, and the more immediate needs of audio traffic. Link Managers also provide a control on power use, through power conservation based on device proximity. Reductions in broadcast strength dictated by the Link Manager can save hours worth of uptime.

The Logical Link Control and Adaptation Protocol (L2CAP) hides lower level details from the higher levels. The changes in frequency are masked at this level, allowing the middleware protocols to remain blissfully ignorant of Bluetooth's frequency hopping. Packets from higher level protocols are also broken up at this level into more bite-sized chunks, suitable for the Baseband/Radio Protocols.

      The HCI Layer is an optional piece of the Transport Layer. In order to facilitate communication between the lowest and highest levels of the protocol stack, the HCI , or Host Controller Interface allows the Application Group of protocols to interact with the baseband and radio layers through a standardized interface. The actual Bluetooth devices as well as applications that may interact with them will be created by several different vendors, making the HCI layer an important standard that will assist companies in implementing Bluetooth devices.

The Middleware Protocol Group connects the Transport level protocols with the

protocols spoken by Bluetooth aware applications. The Middleware group consists of the RFCOMM protocol, the IrDa Interoperability protocol, the Service Discovery Protocol, and the Telephony Control Protocol.

            The RFCOMM protocol allows applications which utilize a serial port to communicate via Bluetooth by presenting legacy serial based applications with a virtual serial port. In this way, devices can utilize programs which facilitate traditional networking, file sharing, and peer to peer communications. Many applications and devices currently use serial ports for communication, making the RFCOMM portion of the protocol stack an important part of Bluetooth.

            One of the most important features of Bluetooth piconets is the ability to form on the fly. The fluid creation and use of these networks requires a means for the nodes on the piconet to discover the services available to them. To this end, the Service Discovery Protocol allows nodes to interrogate each other as to the services they can offer. Once the SDP informs communicating nodes as to the services available to them, normal piconet operations can make use of those services.

            The decision making body known as the Infrared Data Association created several important  protocols and communication standards for use with Infrared Devices. In order to promote communication between Bluetooth nodes and other wireless devices, the SIG decided to add the IrDA protocol layer to the stack. This protocol layer allows intercommunication between devices that "speak" the IrDA protocol and Bluetooth nodes.

            The final distinct layer of the Mid-level protocols is the TCS, or Telephony Control Specification. The telephony layer dictates the ways in which a Bluetooth device sets up audio transmissions. Once the call is established, the call is routed through the standard Bluetooth audio channels. The TCS can also establish a call in the fashion of a modem (to support the network access usage models above). Once the connection is made, the data is shunted through the L2CAP layer, as normal. The TCS is a vital part of making a Bluetooth devices a reliable two-way facilitator of audio communication, and works directly with the Link Layer to assure the special demands of synchronous voice traffic are met.

            This last layer of the protocol stack is not defined by the Bluetooth SIG in any way. This layer of the stack is made up of the actual applications which would interact with the other two layers of the Bluetooth stack Applications to fulfill the various usage models detailed above will obviously be needed, and in fact are likely of most interest to casual enthusiasts. The SIG chose not to define application programming interfaces (APIs), however, nor did it decide on any specific application interface with the lower level protocols. These decisions were designed to produce the most flexible development environment possible for Bluetooth applications.

 The SIG chose not to define an API for any environment because it felt that a technology interest group whose focus was not any one environment should not presume to know better than developers for that environment. In this way, Linux, Windows, and Mac APIs will have to be created by those who know the platforms best. This trust in the separate developer communities will ensure that inappropriate or arbitrary decisions made by the SIG will not limit development in the future.

Not having a specific interface between different levels of the protocol stack allows for freedom of design. Several of the underlying protocols (RFCOMM and IrDA, for example) are intended to allow backwards compatibility with pre-existing applications, as well as for new software to be created for Bluetooth devices using "legacy" software models. New software for Bluetooth may also be created by interfacing directly with the new Bluetooth protocols, such as the L2CAP layer, the Link Manager, and the SDP. By giving the developers of Bluetooth applications a free hand in deciding how to communicate between protocols, the SIG sidestepped restrictions that may have discouraged an attempt to develop for the protocol stack.

With an understanding of the fundamental protocols that make up Bluetooth, it is now possible to take a look at Bluetooth Profiles, which detail (in both broad and specific terms) ways in which a developer can combine the protocols and usage models to create the basis for applications.

Bluetooth Profiles

          Bluetooth Profiles combine the usage models and the protocols in a logical way to produce ideas for building applications and devices. Each of the Bluetooth profiles utilize a different part of the protocol stack, and most of them can be mapped directly to one of the aforementioned usage models. In the interests of reducing confusion, I will use the categories suggested by Bisdikian and Miller's Bluetooth Revealed to discuss the different profiles. These categories are:

• Generic Profiles : Applications meant to facilitate access to Bluetooth devices and services.
• Telephony Profiles : Applications intended to promote voice and audio transmissions.
• Serial Profiles : Applications meant to capitalize on the data transfer capabilities of Bluetooth Nodes.
• Networking Profiles : Applications meant to connect Bluetooth nodes and capitalize on the Piconet architecture.

The Generic Profiles are a special set amongst the profiles. Most Bluetooth devices will not implement all or even most of the profiles. However, it is mandatory for every Bluetooth device to implement the Generic Access Profile (as it describes the basic functionality of a Bluetooth node), and most devices that wish to be a part of a piconet will need to implement the other Generic Profile, the Service Discovery Application Profile.

The Generic Access Profile (GAP) defines, among other things, a common vocabulary for discussing connectivity between Bluetooth nodes at an application or user level. This vocabulary addresses a common misconception among many people who first hear of the capabilities of Bluetooth. While it is possible for a Bluetooth device to interact with every other node it comes into range with, whether or not it does so is a user-set decision. These "Discovery modes" are General (Open to communications), Limited (Open to communications with pre-approved nodes), and NonDiscoverable (closed). The GAP also defines connectability, pairing, and security modes.

The Service Discovery Application Profile (SDAP) dictates the manner in which the Service Discovery Protocol is used to inquire about accessible applications on remote Bluetooth devices. Unlike on a traditional network, where requests are broadcast to all members of the network for discovery of a service, Bluetooth service discovery requests can only be passed between nodes which have established communication via the GAP. Once this communication is established, the SDAP dictates the roles in which the two nodes act. The "local" device implements the Service discovery application, as well as the client end of the protocol. The "remote" device is the server in this relationship, and is queried about what services it has to offer. Generally, the local device is the master of a piconet, wanting to discover and utilize the services of slaves, but this is neither always the case nor a requirement for "local" status.

The Telephony Profiles primarily facilitate voice communications. These profiles interact with the TCS and Baseband layers to ensure reliable audio transmissions. The third profile detailed, the HeadSet profile, technically belongs with the Serial profiles, but is grouped here because of the actual purpose of the profile. The other two profiles detailed are the Cordless Telephony profile, and the Intercom Profile.

The Cordless Telephony Profile (CTP) is one half of the Three-In-One Phone usage model detailed above, with the Intercom Profile, discussed shortly, completing the model. The CTP establishes the conventions by which a handset may be used as a telephone when in contact with a Voice Access Point (VAP). As with normal Bluetooth operations, the phone will initiate a connection with the VAP once it comes within range. However, normal policy makes the initiating node the master of the resultant piconet. This relationship is not desirable in this profile, and thus a role switch is executed, with the handset becoming a slave on the VAP's piconet. This allows the VAP to control the interactions between itself and the slaves, connecting incoming calls and placing outgoing calls when they are requested by associated slaves. An aspect of the master slave relationship discussed earlier was the fact that each master can maintain only up to seven active slaves. As discussed, to maintain connections between more nodes, the master must make decisions to bring devices into and out of a parked mode. The parked mode in this profile is actually a fairly high power one, as once a connection is made between the VAP and handsets, a connection at the L2CAP layer is maintained until the handset leaves the piconet area. This ensures that handsets will be able to instantly receive incoming calls. If the slaves were not in such a high power park, several moments would be needed to establish a reliable enough connection to initiate audio communication, an unacceptable wait by most standards. One final point to consider is security. The assumption this profile works off of is that devices which successfully connect with the VAP will be able to utilize it's services. Thus, only Bluetooth nodes which the VAP recognizes as "trusted" are allowed onto the piconet. "Trusted" nodes are an aspect of security detailed by the GAP.

The Intercom Profile (IntP) details the way in which a direct communication between Bluetooth devices is established. Unlike the CTP, the IntP in unconcerned with the long term master and slave relationships involved. However, in order to forcefully establish an IntP call, it is desirable for the initiator to be the master. Thus, the Profile actually dictates that the Bluetooth node disconnect itself from any piconets it is currently on in order to establish a connection with another node. This profile also discusses the benefits of implementing the Three-in-One model using the more powerful 20dbm radio, with a 100 meter range is used. This more powerful transmitter would allow the Intercom Profile to facilitate communication between persons in crowded stadiums, fair grounds or at conventions without using air time minutes from a cell phone plan.

The final Telephony Profile, the Headset Profile (HSP), as previously mentioned should technically belong under the Serial Profiles, as it utilizes those "legacy" communication protocols built into the Bluetooth stack. The rationale behind this decision was to make the HSP as simple as possible. In addition to accessibility of the serial interface, the Headset Profile does not specify a necessary role for either the Headset or the node providing audio to the Headset. Either can be the master. The less overhead for implementers to include into a Bluetooth Headset, the reasoning goes, the more likely there will be Bluetooth Headsets.

The Serial Profiles are actually two profile sub-sets. The Serial Profile itself, and the profile subset of Object Exchange Profiles make up the overall Serial Profile set. The profiles within the Object Exchange Profile sub-set are: The Generic Object Exchange Profile, the Object Push Profile, the File Transfer Profile, and the Synchronization profile. It should be noted that most of the networking profiles also implement one or more profiles from the Serial Group.

The Serial Port Profile (SPP) is a profile intended to promote the use of Bluetooth nodes with legacy applications. The SPP provides for communications between Bluetooth nodes and other devices via the RFCOMM layer. As it is an abstract profile (much like the required GAP), it is more likely to interact with the middle layers of the Bluetooth stack than with the application layer, with other profiles taking advantage of the RFCOMM connection to facilitate communication.

The GOEP, or Generic Object Exchange Profile, is another abstract profile like the SPP. The more specific Object Exchange Profiles all implement the GOEP, and then implement other profiles with additional functionality on top. The GOEP specifies that each transfer of information has a "client" side and a "server" side. The client side of the transfer is the node which pushes or pulls an object from the server, and the server node is the device which provides the Object Exchange service. These distinctions may sound arbitrary, and in fact only matter to the Object Exchange service. The other layers involved have no knowledge of a node's distinction.

The first of the Object Exchange Profiles, the Object Push Profile (OPP), is primarily concerned with a one-way exchange of information. The profile defines the exchange of an object from a client (the pusher) to a server (the object exchange service provider). This one way exchange is the only necessary functionality of this profile, but the actual object exchange technology specified by the SIG supports limited transfers in the other direction even without additional implementation. These other exchanges are optional to implement in the OPP profile, and can in fact be restricted. Security in the OPP can be handled in any way the implementer feels is appropriate, but the SIG suggests using the trust relationship detailed in the GAP as a basis, with added encryption further securing OPP transfers.

The File Transfer Profile (FP) is an implementation of OPP which allows a less restrictive push and pull exchange. Instead of the more regimented objects which can be used with the OPP, FP states that files and folders can be transferred. Folders are simply lists of available files, and files can be any object available to the Bluetooth device. A typical FP encounter starts with the transfer of a folder to the client from the server. The client (or a user via an application) reviews the available files, and then requests a push from the server of the file, or simply pulls the file from the server. The FP also allows for creation of new files and folders on the server, as well as deleting files from the server. Encryption and use of the trust relationship from the GAP is a mandatory part of the FP, but actual use of the encryption is optional. The File Transfer Profile requires user intervention to accept files from another node as a final safeguard against security problems.

The final Object Exchange Profile is the Synchronization Profile, or SP. The Synchronization profile is a direct support of the Automatic Synchronizer model described above. Like OPP and FP, SP builds on the GOEP, using pushes and pulls to transfer information between two devices. The client in this profile is the "base" device, which establishes a connection with the remote device. This device, which acts as the server, is accessed by the client, who pulls all the pertinent files from the device. The client then compares the copies of the files it has on itself with the files it pulls, and makes any necessary changes, adding any brand new files to its folder (list of files). The updated files are then pushed back to the remote server. This Profile demands some of the highest security measures of any of the profiles, demanding both the bonded and paired relationships dictated by the GAP, as well as mandatory use of encryption.

The last group of profiles is the Networking Profiles. As discussed above, each of these Profiles builds on the GAP, and also on the Serial Port Profile. The Dial Up Networking Profile, and the Fax Profile also build off of some of the Telephony Profiles. The final profile of the Networking group is the LAN Access profile.

The Dial Up Networking Profile (DUNP) shares some similarities with the previously mentioned serial profiles. The DUNP utilizes two Bluetooth nodes to create a connection to the internet. One device, the data terminal, connects to the internet via a gateway device, which utilizes the telephony protocols to make a traditional cellular connection. The RFCOMM protocol layer facilitates communication between the data terminal device and the gateway device. Security in this Profile is handled via the GAP specified pair bonding and trusted relationship. Implementation of these measures are not optional, as is use of the relationships. Further encryption on top of these measures is optional.

The Fax Profile (FaxP) is simply a modified implementation of the DUNP. The transmission from data terminal to gateway, instead of being network packets, are packets containing fax data.

The final networking profile is the LAN Access Profile (LAP). Originally, the LAP and the DUNP were part of a single "Internet Bridge" profile meant to fulfill the usage model of the same name. They were separated when it was realized that, while the two profiles are similar from an end user perspective, the two actually have very different underpinnings. Instead of the gateway device using cellular transmissions to connect to a network (the Internet), as in the DUNP, the LAP connects to a traditional Local Area Network via Point to Point Protocols (PPP). This last connection between the gateway and the LAN itself can either be a wired connection, or utilize an 802.1 wireless connection or even Bluetooth protocols to make the whole process a truly wireless undertaking.

These profiles, taken together with the usage models and protocol outlines, are intended to give interested developers a basis on which to develop Bluetooth devices and applications.

Summary

            The Bluetooth specification is a massive document intended to inform those with an interest in developing Bluetooth devices or applications. This paper has been an attempt to inform those with a casual interest in the technology. The Bluetooth SIG itself, the Bluetooth Usage Models, the Bluetooth Protocols, and the Bluetooth Profiles are all aspects which must be addressed to understand the technology as a whole.

Information References

• The Bluetooth Specifications: http://www.bluetooth.org/specifications.htm
• Bisdikian, Chatschik & Miller, Brent A. BlueTooth Revealed. Prentice Hall PTR, September 21, 2000.