Dr. Andrew Rawicz School of Engineering Science Burnaby, BC V5A 1S6 October 30 th, 2006 Re: ENSC440 Design Specification for VirtualKey (Bluetooth Access Control System) Dear Dr. Rawicz, The following attached document contains Ztronicx Microsystems Design Specification for VirtualKey (a Bluetooth Access Control System). The purpose of VirtualKey is to lock / disable any home appliances while parents / guardians are out of sight and to give temporary access to guests visiting the house via Bluetooth wireless link by a cell phone. The attached design specification includes the following information: Introduction to the VirtualKey Types of Wireless Communication Background VirtualKey Software System Design for Cellular Phones VirtualKey Hardware System Design Test Plans Conclusion Glossary This Design Specification states what VirtualKey will be able to do and describes details of implementations that are being used when the first version is completed in December 2006. If you have any questions or concerns about VirtualKey, you are welcomed to contact Ztronicx Microsystem by email at. Sincerely, Shahin Teymouri Shahin Teymouri President and CEO Ztronicx Microsystem Enclosure: Design Specification for VirtualKey
Design Specification for VirtualKey Bluetooth Access Control System for Home Appliances Project Team: Halim Soetanto May (Mei-Yi) Liu Rick Liu Shahin Teymouri Contact Person: Shahin Teymouri Submitted to: Andrew Rawicz ENSC 440 Steve Whitmore ENSC 305 School of Engineering Science Issued Date: October 30 th, 2006 Revision: 1.0
Executive Summary There have been a lot of cases where problems occur at home while an individual is away such as theft, fire or gas leakage accidents. VirtualKey wireless access control system targets on any unattended or invalid access of home appliances and doors. Adults, especially parents, can prevent their kids from playing with hazardous machines or devices and also if they have caregiver or guests, they could easily give them the access to any door or appliance. The elderly, small children and dementia patients will be safe at home by not triggering any unintentional devices causing an accident. VirtualKey allows the users to fully control lock/unlock and enabling/disabling features over wireless communication by a small plug-and-play module that can be connected to the electrical outlet. Development process of VirtualKey, a wireless access control over home appliances, is divided into two phases. During the first phase, we will be concentrating on proof of concept together with a working prototype which includes the following features: 1. Enable/Disable of home appliances which is determined by detecting the presence of cell phone within range. 2. Provide interface for user to arrange a list of individuals that have access permission by pairing the devices. 3. Encryption and pass-code protection. Upon the successful completion of conceptual working prototype in November, we will extend the functionality of VirtualKey to control lock and unlock behavior of house doors. Page 1 of 43
Table of Contents 1 Introduction... 5 1.1 Scope... 5 1.2 Intended Audience... 5 2. VirtualKey Software System Design... 6 3. VirtualKey Hardware System Design... 7 3.1 Atmel AVR Series ATmega16 Microcontroller... 7 3.2 BlueRadios BlueBR-C40 Bluetooth Module... 11 3.3 Relay... 12 3.4 Power Supply Unit... 14 4. Test Plan... 16 5. Conclusion... 16 6. Glossary... 16 7. Appendix... 18 7.1 Bluetooth Overview... 18 7.2 Background of Bluetooth... 18 7.3 Bluetooth Basics... 19 7.4 Core Specification Versions... 19 7.5 Spectrum... 21 7.6 Interference... 21 7.7 Range & Power... 21 7.8 Data Rate... 22 7.9 Comparison with Other Wireless Technologies... 22 7.10Bluetooth Features... 24 7.11Bluetooth Protocol Stack... 25 7.12Bluetooth Profiles... 27 7.13Bluetooth Network Topology... 28 7.14Low-Power Operating Modes... 30 7.15Bluetooth Security... 30 7.16Java APIs for Bluetooth Wireless Technology... 32 Page 2 of 43
7.17Application Programming... 33 7.18Serial Port Profile (SPP)... 35 7.19Typical Use Cases of a Bluetooth-Enabled Application... 36 7.20Establishing a Network Connection... 37 7.21Discovering Devices and Services... 39 7.22Connecting to a Service... 40 7.23Bluetooth Communication (Creating Channels)... 40 7.24Bluetooth Security... 41 Ztronicx Microsystem Inc. 8. Reference... 43 Page 3 of 43
List of Figures Figure 1: VirtualKey Software Flowchart...6 Figure 2: Sequence Diagram of VirtualKey Cellular Phone Software Application 14...7 Figure 3: Pin configuration for ATmega16 Microcontroller...8 Figure 4: Features of ATmega16 Microcontroller...9 Figure 5: Internal Diagram for ATmega16 Microcontroller...10 Figure 6: AVR ATmega16 with power supply, capacitors and socket connections...11 Figure 7: BlueRadio BR-C40 Bluetooth Module Pins and Dimensions...12 Figure 8: Main Feature of RW/RWH Relays...13 Figure 9: Relay Specifications...13 Figure 10: Relay Physical Specifications...14 Figure 11: Pin diagram for TPS7233 Voltage Regulator...14 Figure 12: Characteristics of TPS7233 Voltage Regulator...15 Figure 13: Typical Application Configuration for TPS7233 Regulator...15 Figure 14: International Radio Frequency Allocation...18 Figure 15: Wireless Piconet and Frequency Hopping...21 Figure 16: Bluetooth Protocol Stack...25 Figure 17: Scatternet Comprising Three Piconets...29 Figure 18: High-level Architecture of J2ME CDLC/MIDP and Bluetooth...33 Figure 19: Typical Use Cases of a Bluetooth-Enabled Application...36 Figure 20: Server and Client Activities...38 Figure 21: Discovering Devices and Services...39 List of Tables Table 1: Atmel AVR Series ATmega16 Microcontroller...7 Table 2: Specification for BlueRadio BlueBR-C40 Bluetooth Module...12 Table 3: Bluetooth Chip Module Class Comparison...22 Page 4 of 43
1 Introduction VirtualKey is a system that eliminates carrying many keys or access cards around to open house, office, or car doors. VirtualKey can also disable dangerous appliances in a house when a person that has access to them is not around so that children will not be able to use them. These two functions of VirtualKey system, acting as a key to all doors and enabling and disabling the appliances, are all integrated into one simple device that you can easy install around your house. VirtualKey has two parts: Java-based software installed on your cellular phone and a hardware module installed behind your appliances or inside your doors. The software installed on your cellular phone will have a user interface that can send different pass codes to the hardware module over a short range wireless system that comes with the cellular phone. The wireless system can use Infrared, Wi-Fi, WiMAX or Bluetooth technology. In this current VirtualKey System, we are concentrating on Bluetooth wireless for the phone-to-module communication. The pass code will travel from the cell phone to the VirtualKey hardware module over a wireless signal. The VirtualKey hardware module can then verify the pass code and activate the door or the appliances. A working model of VirtualKey system will be ready by December 15, 2006 for demo purpose. 1.1 Scope This document describes the design requirements that must be met for the VirtualKey access control system. This is the current design specification we are planning to implement for our first release. As we develop the VirtualKey system for the demo model in December, we might change some minor aspects of this design specification for further improvement. However the foundation of this design specification will not change. 1.2 Intended Audience Design engineers will use this document as the foundation for building the Virtual Key system. Project managers will use this document to measure the performance, development objectives and to see if this project is following the required design. Marketing team will use this document to create the initial advertisement and promotional content. Page 5 of 43
2. VirtualKey Software System Design The figure below shows how a basic flowchart for the VirtualKey software residing on the cell phone. Figure 1: VirtualKey Software Flowchart Page 6 of 43
Figure 2: Sequence Diagram of VirtualKey Cellular Phone Software Application 14 3. VirtualKey Hardware System Design Below are the list of the components, their specifications, and the configuration that they will be used in the VirtualKey Hardware Module. 3.1 Atmel AVR Series ATmega16 Microcontroller Below are the specifications for Atmel AVR ATmega16 microcontroller which VirtualKey hardware module will be using: Flash EEPROM SRAM Speed Volts 16kB 512B 1024B 0-16MHz 4.5-5.5V Table 1: Atmel AVR Series ATmega16 Microcontroller Page 7 of 43
Figure 3: Pin configuration for ATmega16 Microcontroller 1 Page 8 of 43
Figure 4: Features of ATmega16 Microcontroller 2 Page 9 of 43
Figure 5: Internal Diagram for ATmega16 Microcontroller 3 Page 10 of 43
The diagram below shows AVR ATmega16 on daughter board with power supply, capacitors and the socket connections Figure 6: AVR ATmega16 with power supply, capacitors and socket connections 4 3.2 BlueRadios BlueBR-C40 Bluetooth Module 5 Below is the list of features of the BlueRadios BlueBR-C40 Bluetooth Module: Class1, Class2, and Class3 Bluetooth ver2.0 Wireless communications module certified to Bluetooth ver2.0. FCC, CE, RoHS, and Bluetooth certified ISM 2.4GHz band module. UART data interface (2-wire or 4-wire with CTS/RTS). 13-bit PCM, 8k samples/s, synchronous bidirectional audio interface Includes integrated software stack, profiles, and AT modem like commands. Embedded Bluetooth Stack Profiles Included (requires no host MCU stack): SPP, DUN, LAN, Headset, Audio Gateway, FTP Client, OBEX, OPP Push/Pull, GAP SDP, RFCOMM, and L2CAP protocols. Page 11 of 43
Table 2: Specification for BlueRadio BlueBR-C40 Bluetooth Module 6 Figure 7: BlueRadio BR-C40 Bluetooth Module Pins and Dimensions 7 3.3 Relay VirtualKey hardware modules are using RW/RWH relays. Page 12 of 43
Figure 8: Main Feature of RW/RWH Relays 8 Figure 9: Relay Specifications 9 Page 13 of 43
Figure 10: Relay Physical Specifications 10 3.4 Power Supply Unit VirtualKey hardware modules are using TPS7233 from Texas Instrument as the voltage regulator. Figure 11: Pin diagram for TPS7233 Voltage Regulator 11 TPS7233 Voltage Regulator has the following characteristics: Page 14 of 43
Figure 12: Characteristics of TPS7233 Voltage Regulator 12 Figure 13: Typical Application Configuration for TPS7233 Regulator 13 Page 15 of 43
4. Test Plan The VirtualKey system can be fully tested with a wireless capable cell phone. The VirtualKey java software will be downloaded into a cellular phone; it can then add the hardware modules that are in near proximity to its internal list. After the hardware modules have been added to the list, the cellular phone can send the pass codes to the right module to activate them. This system can be fully demonstrated. There is no need to have an appliance ready. A desk lamp can be used as an appliance. As for the door unlocking, a door actuator can be installed in a nearby door for demonstration. Both can be done in any room or environment. We are also planning to test the appliance module in an environment where kids as well as Dementia patients available to see how our module will disable the dangerous appliances when a caregiver is not around the appliances. Test Cases: If Bluetooth is out of range, the appliance will work for another extra 10 minutes If a cell phone is not available to enable appliances, a keypad can be used to enter a pass code to bypass the cell phone and enable the appliances. When power fails or during a brownout/surge the unit will properly reset itself and will continue the previous state. If the pass code is entered into the Virtual Key module several times during a short period of time, the hardware module will disable Bluetooth for 5 minutes. 5. Conclusion This document dictates the design specification for both VirtualKey hardware and software components. We are planning to have a very basic working model by beginning of November and the remaining functionality integrated by beginning of December. A demo model will be available by middle of December, and we will follow the test plan and test cases for demonstration. 6. Glossary Adaptive Frequency-hopping spread spectrum (AFH) Adaptive Frequency-hopping spread spectrum (AFH) (as used in Bluetooth) improves resistance to radio frequency interference by avoiding using crowded frequencies in the hopping sequence. This sort of adaptive modulation is easier to implement with FHSS than with DSSS. Industrial-Scientific-Medical (ISM) Band The industrial, scientific and medical (ISM) radio bands were originally reserved internationally for non-commercial use of RF electromagnetic fields for industrial, scientific and medical purposes. The ISM bands are defined by the ITU-R in 5.138 and 5.150 of the Radio Regulations. Individual Page 16 of 43
countries' use of the bands designated in these sections may differ due to variations in national radio regulations. In the United States of America ISM is governed by Part 18 of the FCC rules and should not be confused with Part 15 rules. Communication is not permitted under Part 18 (ISM) rules. Piconets A piconet is an ad-hoc computer network of devices using Bluetooth technology protocols to allow one master device to interconnect with up to seven active slave devices (because a three-bit MAC address is used). Up to 255 further slave devices can be inactive, or parked, which the master device can bring into active status at any time. Page 17 of 43
7. Appendix The content of the appendix below explains about various wireless communications technologies available and detailed guidelines for developing Bluetooth-enabled hand-held devices using Java API. The following appendix is taken from various sources listed below: http://developers.sun.com/techtopics/mobility/midp/articles/bluetooth1/ http://developers.sun.com/techtopics/mobility/apis/articles/bluetoothintro/ http://developers.sun.com/techtopics/mobility/apis/articles/bluetoothcore/ www.bluetooth.com/bluetooth/learn/basics/ www.bluetooth.com/bluetooth/learn/technology/compare/ www.bluetooth.com/bluetooth/learn/works/profiles_overview.htm http://en.wikipedia.org/wiki/bluetooth/ 7.1 Bluetooth Overview Electronic devices can connect to the other hardware in a variety of ways: a RGB cable connects a computer's VGA unit to a monitor display, a RS-232 data cable connects a terminal device to serial port, radio waves connect a cordless phone to its base unit, and an infrared beam connects a remote control to a television. The elaborate array of connectors among electronic devices requires a better solution. Bluetooth is a completely different way to form connections between electronic devices. It s one kind of cable-replacement technologies, but its applications are wild. Bluetooth does more than just replace cables. It is a radio-frequency technology that uses the 2.4 GHz Industrial- Scientific-Medical (ISM) band. If one has a home cordless phone or a garage-door opener he is already using the ISM band. Figure 14: International Radio Frequency Allocation 1 7.2 Background of Bluetooth The Bluetooth wireless connectivity technology was originally envisioned in 1994 by the Swedish phone equipment maker Ericsson as a way for mobile devices to communicate with each other at short ranges (up to 30 feet or 10 meters). In 1998, Ericsson, IBM, Intel, Nokia, and Toshiba formed the Bluetooth Special Interest Group consortium to develop a royalty-free, Page 18 of 43
open specification for short-range wireless connectivity. Since then, more than 2000 companies have joined the Bluetooth SIG, including virtually all manufacturers of phone, computer, and PDA equipment. Bluetooth is also known as IEEE 802.15.1. While Bluetooth is positioned as a replacement for cable, infrared, and other connection media, it offers a variety of other services, and creates opportunities for new usage models. For instance, it's also a good technology for synchronizing devices. It works quietly, unconsciously, and automatically in the background. "Bluetooth" was the nickname of Harald Blåtland II (Harald Bluetooth), king of Denmark from 940 to 981, who united all of Denmark and part of Norway under his rule. He managed to unite Denmark and part of Norway into a single kingdom and then introduced Christianity into Denmark. He left a large monument, the Jelling rune stone, in memory of his parents. He was killed in 986 during a battle with his son, Svend Forkbeard. Choosing this name for the standard indicates how important companies from the Nordic region (nations including Denmark, Sweden, Norway and Finland) are to the communications industry, even if it says little about the way the technology works. 7.3 Bluetooth Basics Bluetooth wireless technology is a short-range communications technology intended to replace the cables connecting portable and/or fixed devices while maintaining high levels of security. The key features of Bluetooth technology are robustness, low power, and low cost. The Bluetooth specification defines a uniform structure for a wide range of devices to connect and communicate with each other. Bluetooth technology has achieved global acceptance such that any Bluetooth enabled device, almost everywhere in the world, can connect to other Bluetooth enabled devices in proximity. Bluetooth enabled electronic devices connect and communicate wirelessly through short-range, ad hoc networks known as piconets. Each device can simultaneously communicate with up to seven other devices within a single piconet. Each device can also belong to several piconets simultaneously. Piconets are established dynamically and automatically as Bluetooth enabled devices enter and leave radio proximity. A fundamental Bluetooth wireless technology strength is the ability to simultaneously handle both data and voice transmissions. This enables users to enjoy variety of innovative solutions such as a hands-free headset for voice calls, printing and fax capabilities, and synchronizing PDA, laptop, and mobile phone applications to name a few. 7.4 Core Specification Versions Bluetooth 1.0 and 1.0B Versions 1.0 and 1.0 B had many problems and the various manufacturers had great difficulties in making their products interoperable. 1.0 and 1.0B also had mandatory Page 19 of 43
Bluetooth Hardware Device Address (BD_ADDR) transmission in the handshaking process, rendering anonymity impossible at a protocol level, which was a major setback for services planned to be used in Bluetooth environments, such as Consumerism. Bluetooth 1.1 Many errors found in the 1.0B specifications were fixed. Added support for non-encrypted channels. Received Signal Strength Indicator (RSSI) Bluetooth 1.2 This version is backwards compatible with 1.1 and the major enhancements include: Adaptive Frequency-hopping spread spectrum (AFH), which improves resistance to radio frequency interference by avoiding the use of crowded frequencies in the hopping sequence Higher transmission speeds in practice Extended Synchronous Connections (esco), which improves voice quality of audio links by allowing retransmissions of corrupted packets. Host Controller Interface (HCI) support for 3-wire UART HCI access to timing information for Bluetooth applications: Bluetooth 2.0 This version is backwards compatible with 1.x. The main enhancement is the introduction of Enhanced Data Rate (EDR) of 3.0 Mbps. This has the following effects (Bluetooth SIG, 2004): 3 times faster transmission speed (up to 10 times in certain cases). 100 meter range Lower power consumption through a reduced duty cycle. Simplification of multi-link scenarios due to more available bandwidth. Further improved BER (bit error rate) performance. Future of Bluetooth The next version of Bluetooth technology, currently code-named Lisbon, includes a number of features to increase security, usability and value of Bluetooth. The following features are defined: Atomic Encryption Change - allows encrypted links to change their encryption keys periodically, increasing security, and also allowing role switches on an encrypted link. Extended Inquiry Response - provides more information during the inquiry procedure to allow better filtering of devices before connection. This information includes the name of the device, and a list of services, with other information. Sniff Subrating - reducing the power consumption when devices are in the sniff lowpower mode, especially on links with asymmetric data flows. Human interface devices (HID) are expected to benefit the most, with mice and keyboards increasing the battery life from 3 to 10 times those currently used. QoS Improvements - these will enable audio and video data to be transmitted at a higher quality, especially when best effort traffic is being transmitted in the same piconet. Page 20 of 43
Simple Pairing - this improvement will radically improve the pairing experience for Bluetooth devices, while at the same time increasing the use and strength of security. It is expected that this feature will significantly increase the use of Bluetooth. Specification Make-Up Unlike many other wireless standards, the Bluetooth wireless specification gives product developers both link layer and application layer definitions, which supports data and voice applications. 7.5 Spectrum Bluetooth technology operates in the unlicensed industrial, scientific and medical (ISM) band at 2.4 to 2.485 GHz, using a spread spectrum, frequency hopping, full-duplex signal at a nominal rate of 1600 hops/sec. The 2.4 GHz ISM band is available and unlicensed in most countries. Figure 15: Wireless Piconet and Frequency Hopping 1 7.6 Interference Bluetooth technology s adaptive frequency hopping (AFH) capability was designed to reduce interference between wireless technologies sharing the 2.4 GHz spectrum. AFH works within the spectrum to take advantage of the available frequency. This is done by detecting other devices in the spectrum and avoiding the frequencies they are using. This adaptive hopping allows for more efficient transmission within the spectrum, providing users with greater performance even if using other technologies along with Bluetooth technology. The signal hops among 79 frequencies at 1 MHz intervals to give a high degree of interference immunity. 7.7 Range & Power The operating range depends on the device class: Page 21 of 43
Bluetooth Chip Module Class Class 1 Class 2 Class 3 Distance 100 m 50~20 m 10 m Power 100mW (20dBm) 2.5mW (4dBm) 1mW (0dBm) Table 3: Bluetooth Chip Module Class Comparison 7.8 Data Rate 1 Mbps for Version 1.2; Up to 3 Mbps supported for Version 2.0 + EDR 7.9 Comparison with Other Wireless Technologies 1 The wireless world continues to grow as engineers develop faster, more robust technologies to free us from wires for greater simplicity, convenience, and efficiency. A comparison of Bluetooth technology with other wireless technologies is helpful when making decisions. Bluetooth Wireless Technology Bluetooth wireless technology is geared towards voice and data applications Bluetooth wireless technology operates in the unlicensed 2.4 GHz spectrum Bluetooth wireless technology can operate over a distance of 10 meters or 100 meters depending on the Bluetooth device class. The peak data rate with EDR is 3 Mbps Bluetooth wireless technology is able to penetrate solid objects Bluetooth technology is omni-directional and does not require line-of-sight positioning of connected devices Security has always been and continues to be a priority in the development of the Bluetooth specification. The Bluetooth specification allows for three modes of security The cost of Bluetooth chips is under $3 Ultra-Wideband (UWB) UWB is a revolutionary wireless technology for transmitting digital data over a wide spectrum of frequency bands with very low power. It can transmit data at very high rates (for wireless local area network applications) To date, UWB only has regulatory approval in the United States. UWB products are slow to come to market due to the disagreements over the standard and the lack of global regulatory approval Ideally, it will have low power consumption, low price, high speed, use a wide swath of radio spectrum, carry signals through obstacles (doors, etc.) and apply to a wide range of applications (defense, industry, home, etc.) Currently, there are two competing UWB standards. The UWB Forum is promoting one standard based on direct sequence (DS-UWB). The WiMedia Alliance is promoting another standard based on Multi-band Orthogonal Frequency Division Modulation (OFDM) Each standard allows for data rates from approximately 0-500 Mbps at a range of 2 meters and a data rate of approximately 110 Mbps at a range of up to 10 meters Page 22 of 43
The Bluetooth SIG announced in May 2005 its intentions to work with both groups behind UWB to develop a high rate Bluetooth specification on the UWB radio Certified Wireless USB Speed: Wireless USB is projected to be 480 Mbps up to 2 meters and 110 Mbps for up to 10 meters. Wireless USB hub can host up to 127 wireless USB devices Wireless USB will be based on and run over the UWB radio promoted by the WiMedia Alliance. Allows point-to-point connectivity between devices and the Wireless USB hub Intel established the Wireless USB Promoter Group in February 2004 The USB Implementers Forum, Inc. (USB-IF) tests and certifies the "certified Wireless USB" based wireless equipment Wi-Fi (IEEE 802.11) Bluetooth technology costs a third of Wi-Fi to implement Bluetooth technology uses a fifth of the power of Wi-Fi The Wi-Fi Alliance tests and certifies 802.11 based wireless equipment 802.11a: This uses OFDM, operates in the 5 GHz range, and has a maximum data rate of 54 Mbps 802.11b: Operates in the 2.4 GHz range, has a maximum data rate of 11 Mbps and uses DSSS. 802.11b is the original Wi-Fi standard 802.11g: Operates in the 2.4 GHz range, uses OFDM and has a maximum data rate of 54 Mbps. This is backwards compatible with 802.11b 802.11e: This standard will improve quality of service 802.11h: This standard is a supplement to 802.11a in Europe and will provide spectrum and power control management. Under this standard, dynamic frequency selection (FS) and transmit power control (TPC) are added to the 802.11a specification 802.11i: This standard is for enhanced security. It includes the advanced encryption standard (AES). This standard is not completely backwards compatible and some users will have to upgrade their hardware. The full 802.11i support is also referred to as WPA2 802.11k: Under development, this amendment to the standard should allow for increased radio resource management on 802.11 networks 802.11n: This standard is expected to operate in the 5 GHz range and offer a maximum data rate of over 100 Mbps (though some proposals are seeking upwards of 500 Mbps). 802.11n will handle wireless multimedia applications better than the other 802.11 standards 802.11p: This standard will operate in the automotive-allocated 5.9 GHz spectrum. It will be the basis for the dedicated short range communications (DSRC) in North America. The DSRC will allow vehicle to vehicle and vehicle to roadside infrastructure communication 802.11r: This amendment to the standard will improve users ability to roam between access points or base stations. The task group developing this form in spring/summer 2004 802.11s: Under development, this amendment to the standard will allow for mesh networking on 802.11 networks. The task group developing this formed in Page 23 of 43
spring/summer 2004 WiMAX (Worldwide Interoperability for Microwave Access and IEEE 802.16) WiMax is a wireless metropolitan area network (MAN) technology WiMax has a range of 50 km with data rates of 70 Mbps. Typical cell has a shorter range The original 802.16 standard operated in the 10-66 GHz frequency bands with line of sight environments The newly completed 802.16a standard operates between 2 and 11 GHz and does not need line of sight Delays in regulatory approval in Europe due to issues regarding the use of the spectrums in the 2.8 GHz and 3.4 GHz range Supports vehicle mobility for between 20 to 100+ km/hr. The 802.16e standard will allow nomadic portability The IEEE 802.16a and the ETSI HIPERMAN (High Performance Radio Metropolitan Area Network) share the same PHY and MAC. 802.16 has been designed from the beginning to be compatible with the European standard Created to compete with DSL and cable modem access, the technology is considered ideal for rural, hard to wire areas Infrared (IrDA) IrDA is used to provide wireless connectivity for devices that would normally use cables to connect. IrDA is a point-to-point, narrow angle (30 cone), ad-hoc data transmission standard designed to operate over a distance of 0 to 1 meter and at speeds of 9600 bps to 16 Mbps IrDA is not able to penetrate solid objects and has limited data exchange applications compared to other wireless technologies IrDA is mainly used in payment systems, in remote control scenarios or when synchronizing two PDAs with each other Radio Frequency Identification (RFID) There are over 140 different ISO standards for RFID for a broad range of applications With RFID, a passive or unpowered tag can be powered at a distance by a reader device. The receiver, which must be within a few feet, pulls information off the tag, and then looks up more information from a database. Alternatively, some tags are self-powered, active tags that can be read from a greater distance RFID can operate in low frequency (less than 100 MHz), high frequency (more than 100 MHz), and UHF (868 to 954 MHz) Uses include tracking inventory both in shipment and on retail shelves 7.10Bluetooth Features The major features of Bluetooth are: Bluetooth is wireless and automatic. People don't have to keep track of cables, connectors, and connections, and people don't need to do anything special to initiate communications. Devices find each other automatically and start conversing without user input, expect where Page 24 of 43
authentication is required; for example, users must log in to use their email accounts. Bluetooth is inexpensive. Market analysts peg the cost to incorporate Bluetooth technology into a PDA, cell phone, or other product at around $20 now, and say that it could fall to as little as $5 per unit. The ISM band that Bluetooth uses is regulated, but unlicensed. Governments have converged on a single standard, so it's possible to use the same devices virtually wherever a person travels, and he doesn t need to obtain legal permission in advance to begin using the technology. Bluetooth handles both data and voice. Its ability to handle both kinds of transmissions simultaneously makes possible such innovations as a mobile hands-free headset for voice with applications that print to fax, and that synchronize the address books on his PDA, his laptop, and his cell phone. Signals are omni-directional and can pass through walls and briefcases. Communicating devices don't need to be aligned and don't need an unobstructed line of sight. Bluetooth uses frequency hopping. Its spread spectrum approach greatly reduces the risk that communications will be intercepted. 7.11 Bluetooth Protocol Stack The Bluetooth protocol stack provides a number of higher-level protocols and APIs for service discovery and serial I/O emulation, and a lower-level protocol for packet segmentation and reassembly, protocol multiplexing, and quality of service. Figure 16: Bluetooth Protocol Stack 1 The responsibilities of the layers in this stack are as follows: Page 25 of 43
Bluetooth Radio The radio layer is the physical wireless connection. To avoid interference with other devices that communicate in the ISM band, the modulation is based on fast frequency hopping. Bluetooth divides the 2.4 GHz frequency band into 79 channels 1 MHz apart (from 2.402 to 2.480 GHz), and uses this spread spectrum to hop from one channel to another, up to 1600 times a second. The standard wavelength range is 10 cm to 10 m, and can be extended to 100 m by increasing transmission power. Baseband Link Controller The baseband layer is responsible for controlling and sending data packets over the radio link. It provides transmission channels for both data and voice. The baseband layer maintains Synchronous Connection-Oriented (SCO) links for voice and Asynchronous Connectionless (ACL) links for data. SCO packets are never retransmitted but ACL packets are, to ensure data integrity. SCO links are point-to-point symmetric connections, where time slots are reserved to guarantee timely transmission. A slave device is allowed to respond during the time slot immediately following an SCO transmission from the master. A master can support up to three SCO links to a single slave or to multiple slaves, and a single slave can support up to two SCO links to different slaves. Data transmissions on ACL links, on the other hand, are established on a per-slot basis (using slots not reserved for SCO links). ACL links support point-to-multipoint transmissions. After an ACL transmission from the master, only a slave addressed specifically may respond during the next time slot; if no device is addressed, the message is treated as a broadcast. Link Manager Protocol (LMP) The LMP uses the links set up by the baseband to establish connections and manage piconets. Responsibilities of the LMP also include authentication and security services, and monitoring of service quality. Host Controller Interface (HCI) The HCI is the dividing line between software and hardware. The L2CAP and layers above it are currently implemented in software, and the LMP and lower layers are in hardware. The HCI is the driver interface for the physical bus that connects these two components. The HCI may not be required. The L2CAP may be accessed directly by the application, or through certain support protocols provided to ease the burden on application programmers. Logical Link Control and Adaptation Protocol (L2CAP) The L2CAP receives application data and adapts it to the Bluetooth format. Quality of Service (QoS) parameters are exchanged at this layer. Page 26 of 43
For VirtualKey product, it utilizes Bluetooth Host Protocol Stack (software). The software is built upon L2CAP protocol and using RFCOMM protocol (Serial Emulation channel) to communicate and exchange data between cell phone and home appliances. 7.12Bluetooth Profiles In order to use Bluetooth wireless technology, a device must be able to interpret certain Bluetooth profiles. Bluetooth profiles are intended to ensure interoperability among Bluetoothenabled devices and applications from different manufacturers and vendors. A profile defines the roles and capabilities for specific types of applications. Note well that Bluetooth devices cannot interact unless they conform to a particular profile; in other words, having the bare minimum Bluetooth stack isn't enough. By following a guidance provided in Bluetooth specifications, developers can create applications to work with other devices also conforming to the Bluetooth specification. All of the Bluetooth profiles are defined in Volume II of the Bluetooth specification. They include the Generic Access Profile that defines device-management functionality, the Service Discover Application Profile that defines the aspects of service discovery, and the Serial Port Profile that defines the interoperability requirements and capabilities for serial cable emulation. Here are some of them: Generic Access Profile (GAP) The GAP defines connection procedures, device discovery, and link management. It also defines procedures related to use of different security models and common format requirements for parameters accessible on the user interface level. At a minimum all Bluetooth devices must support this profile. GAP provides the basis for all other profiles and defines a consistent means to establish a baseband link between Bluetooth enabled devices. In addition to this, GAP defines the following: u The features must be implemented in all Bluetooth devices u Generic procedures for discovering and linking to devices u Basic user-interface terminology GAP ensures a high degree of interoperability between applications and devices. It also makes it easier for developers to define new profiles by leveraging existing definitions. GAP handles discovery and establishment between devices that are unconnected. The profile defines operations that are generic and can be used by profiles referring to GAP and by devices implementing multiple profiles. GAP ensures that any two Bluetooth enabled devices, regardless of manufacturer and application, can exchange information via Bluetooth technology in order to discover what type of applications the devices support. Bluetooth enabled devices not conforming to any other Bluetooth profile must conform to GAP to ensure basic interoperability and co-existence. Service Discovery Application Profile (SDAP) The SDAP defines the features and procedures for an application in a Bluetooth device to Page 27 of 43
discover services registered in other Bluetooth devices, and retrieves information related to the services. SDAP describes how an application should use SDP to discover services on a remote device. As required by the GAP, any Bluetooth enabled device should be able to connect to any other Bluetooth enabled device. Based on this, SDAP requires that any application be able to find out what services are available on any Bluetooth enabled device it connects to. The profile handles the search for known and specific services as well as searches for general services. SDAP involves an application, the service discovery user application, which is required in a Bluetooth device for locating services. This application interfaces with the SDP that sends and receives service inquiries to and from other Bluetooth enabled devices. SDAP is dependent on and re-uses parts of the GAP Serial Port Profile (SPP) The SPP defines the requirements for Bluetooth devices that need to set up connections that emulate serial cables and use the RFCOMM protocol. SPP defines how to set-up virtual serial ports and connect two Bluetooth enabled devices. SPP is based on the ETSI TS07.10 specification and uses the RFCOMM protocol to provide serial-port emulation. SPP provides a wireless replacement for existing RS-232 based serial communications applications and control signals. SPP provides the basis for the DUN, FAX, HSP and LAN profiles. This profile supports a data rate of up to 128kbit/sec. SPP is dependent on GAP. At a minimum, each profile specification contains information on the following topics: Dependencies on other profiles Suggested user interface formats Specific parts of the Bluetooth protocol stack used by the profile. To perform its task, each profile uses particular options and parameters at each layer of the stack. This may include an outline of the required service record, if appropriate 7.13Bluetooth Network Topology Bluetooth-enabled devices are organized in groups called piconets. A piconet consists of a master (home appliance) and up to seven active slaves (cell phone). A master and a single slave use point-to-point communication; if there are multiple slaves; point-to-multipoint communication is used. A master unit is the device that initiates the communication. A device in one piconet can communicate to another device in another piconet, forming a scatternet, as depicted in the following figure. Notice that a master in one piconet may be a slave in another piconet: Page 28 of 43
Figure 17: Scatternet Comprising Three Piconets 1 The normal duration of transmission is one slot, and a packet can last up to five time slots in length. In order to support full-duplex communications, Bluetooth uses a time-division multiplexing (TDM) scheme, in which a master device always uses an even-numbered slot when it transmits, and a slave uses an odd-numbered slot. Any time a Bluetooth wireless link is formed, it is within the context of a piconet. A piconet consists of two or more devices that occupy the same physical channel (which means that they are synchronized to a common clock and hopping sequence). The common (piconet) clock is identical to the Bluetooth clock of one of the devices in the piconet, known as the master of the piconet, and the hopping sequence is derived from the master s clock and the master s Bluetooth device address. All other synchronized devices are referred to as slaves in the piconet. The terms master and slave are only used when describing these roles in a piconet. Within a common location a number of independent piconets may exist. Each piconet has a different physical channel (that is a different master device and an independent piconet clock and hopping sequence). A Bluetooth enabled device may participate concurrently in two or more piconets. It does this on a time-division multiplexing basis. A Bluetooth enabled device can never be a master of more than one piconet. (Since the piconet is defined by synchronization to the master s Bluetooth clock it is impossible to be the master of two or more piconets.) A Bluetooth enabled device may be a slave in many independent piconets. A Bluetooth enabled device that is a member of two or more piconets is said to be involved in a scatternet. Involvement in a scatternet does not necessarily imply any network routing capability or function in the Bluetooth enabled device. The Bluetooth core protocols do not, and are not intended to offer such functionality, which is the responsibility of higher level protocols and is outside the scope of the Bluetooth core specification. ogical transports, logical links and L2CAP channels are used to provide capabilities for the transport of data. Page 29 of 43
7.14Low-Power Operating Modes Bluetooth defines provisions for three low-power operating modes in order to conserve battery life: Sniff Mode A slave (cell phone) listens at a reduced level and doesn't take an active role in the piconet Sniff mode is not a general device mode but applies to the default ACL logical transports. When in this mode, the availability of these logical transports is modified by defining a duty cycle consisting of periods of presence and absence. Devices that have their default ACL logical transports in sniff mode may use the absent periods to engage in activity on another physical channel, or to enter reduced power mode. The periods of presence and absence of the physical link on the piconet physical channel is derived as a union of all logical transports that are built on the physical link. Hold Mode A device in hold mode transmits no data, but its clock continues to operate, and a slave (cell phone) remains in synchronization with the master (home appliances). The device is not an active member of the piconet, but it retains its active member address. Power requirements decrease as a device goes from sniff to hold. Hold mode is not a general device mode but applies to unreserved slots on the physical link. All asynchronous links are inactive. Hold modes operate once for each invocation and are then exited when complete, returning to the previous mode. Park Mode Park mode is like hold mode in that the slave is synchronized to the master but is not part of the traffic. In this mode, however, the slave doesn't retain its active member address. Power requirements decrease still further as a device goes from hold to park. A slave device may remain connected to a piconet but have its physical link in the parked mode. In this mode, the device cannot support any logical links to the master with the exception of the PSB-C and PSB-U logical links that are used for all communication between the piconet master and the parked slave. When the physical link to a slave device is parked this means that there are restrictions on when the master and slave may communicate, defined by the PSB logical transport parameters. During times when the PSB logical transport is inactive (or absent) then the devices may engage in activity on other physical channels, or enter reduced power mode. 7.15Bluetooth Security In any wireless networking setup, security is a concern. Devices can easily grab radio waves out of the air, so people who send sensitive information over a wireless connection need to take precautions to make sure those signals aren't intercepted. Bluetooth technology is no different it's wireless and therefore susceptible to spying and remote access, just like WiFi being susceptible if the network isn't secure. With Bluetooth, though, the automatic nature of the connection, which is a huge benefit in terms of time and effort, is also a benefit to people looking to send one data without his permission. Page 30 of 43
Bluetooth offers several security modes, and device manufacturers determine which mode to include in a Bluetooth-enabled gadget. In almost all cases, Bluetooth users can establish "trusted devices" that can exchange data without asking permission. When any other device tries to establish a connection to the user's gadget, the user has to decide to allow it Security is provided in three ways: pseudo-random frequency hopping, authentication, and encryption: Frequency hops make it difficult for anyone to eavesdrop. Authentication allows a user to limit connectivity to specified devices. Encryption uses secret keys to make data intelligible only to authorized parties. All Bluetooth-enabled devices must implement the Generic Access Profile (GAP), which contains all the Bluetooth protocols and possible devices. This profile defines a security model that includes three security modes: Mode 1 is an insecure mode of operation. No security procedures are initiated. Mode 2 is known as service-level enforced security. When devices operate in this mode, no security procedures are initiated before the channel is established. This mode enables applications to have different access policies and run them in parallel. Mode 3 is known as link-level enforced security. In this mode, security procedures are initiated before link setup is complete. The authentication method built into Bluetooth authenticates the device and not the device's user or owner, so the user must consider the use of an application-layer security program and take care that the device itself doesn't fall into the hands of a third party. Service-level security and device-level security work together to protect Bluetooth devices from unauthorized data transmission. Security methods include authorization and identification procedures that limit the use of Bluetooth services to the registered user and require that users make a conscious decision to open a file or accept a data transfer. As long as these measures are enabled on the user's phone or other device, unauthorized access is unlikely. A user can also simply switch his Bluetooth mode to "non-discoverable" and avoid connecting with other Bluetooth devices entirely. If a user makes use of the Bluetooth network primarily for synching devices at home, this might be a good way to avoid any chance of a security breach while in public. Still, early cell-phone virus writers have taken advantage of Bluetooth's automated connection process to send out infected files. However, since most cell phones use a secure Bluetooth connection that requires authorization and authentication before accepting data from an unknown device, the infected file typically doesn't get very far. When the virus arrives in the user's cell phone, the user has to agree to open it and then agree to install it. This has, so far, stopped most cell-phone viruses from doing much damage. Other problems like "bluejacking," "bluebugging" and "Car Whisperer" have turned up as Bluetooth-specific security issues: Bluejacking involves Bluetooth users sending a business card (just a text message, really) to other Bluetooth users within a 10-meter (32-foot) radius. If the user doesn't realize what the Page 31 of 43
message is, he might allow the contact to be added to his address book, and the contact can send him messages that might be automatically opened because they're coming from a known contact. Bluebugging is more of a problem, because it allows hackers to remotely access a user's phone and use its features, including placing calls and sending text messages, and the user doesn't realize it's happening. The Car Whisperer is a piece of software that allows hackers to send audio to and receive audio from a Bluetooth-enabled car stereo. Like a computer security hole, these vulnerabilities are an inevitable result of technological innovation, and device manufacturers are releasing firmware upgrades that address new problems as they arise. 7.16Java APIs for Bluetooth Wireless Technology Bluetooth is a low-cost, short-range wireless technology that has become popular among those who want to create personal area networks (PANs). To support development of Bluetoothenabled software on the Java platform, the Java Community Process (JCP) has defined JSR 82, the Java APIs for Bluetooth Wireless Technology (JABWT). JSR 82 is the first open, non-proprietary standard for developing Bluetooth applications using the Java programming language. It hides the complexity of the Bluetooth protocol stack behind a set of Java APIs that allow developers to focus on application development rather than the low-level details of Bluetooth. JSR 82 is based on version 1.1 of the Bluetooth Specification. JSR 82 consists of two optional packages: the core Bluetooth API and the Object Exchange (OBEX) API. The latter is transport-independent and can be used without the former. The Java APIs for Bluetooth target devices with the following characteristics: 512K minimum of total memory available (ROM and RAM) (application memory requirements are additional) Bluetooth wireless network connection Compliant implementation of the J2ME Connected Limited Device Configuration (CLDC) The API is intended to provide the following capabilities: Register services Discover devices and services Establish RFCOMM, L2CAP, and OBEX connections between devices Using those connections, send and receive data (voice communication not supported) Manage and control the communication connections Provide security for these activities JSR 82 requires that the Bluetooth stack underlying a JSR 82 implementation be qualified for the Generic Access Profile, the Service Discovery Application Profile, and the Serial Port Profile. The stack must also provide access to its Service Discovery Protocol, and to the RFCOMM and L2CAP layers. Page 32 of 43
The APIs are designed in such a way that developers can use the Java programming language to build new Bluetooth profiles on top of this API as long as the core layer specification does not change. To promote this flexibility and extensibility, the specification is not restricted to APIs that implement Bluetooth profiles. JSR 82 includes APIs for OBEX and L2CAP so that future Bluetooth profiles can be implemented in Java. The following figure shows where the APIs defined in this specification fit in CLDC/MIDP architecture. Figure 18: High-level Architecture of J2ME CDLC/MIDP and Bluetooth 1 The Java APIs for Bluetooth define two packages that depend on the CLDC javax.microedition.io package: javax.bluetooth: core Bluetooth API javax.obex: APIs for the Object Exchange (OBEX) protocol 7.17Application Programming A Bluetooth application has five parts: stack initialization, device management, device discovery, service discovery, and communication. Stack Initialization The Bluetooth stack is responsible for controlling the Bluetooth device, so we need to initialize the Bluetooth stack before we can do anything else. The initialization process comprises a number of steps whose purpose is to get the device ready for wireless communication. Unfortunately, the Bluetooth specification leaves implementation of the BCC to vendors, and Page 33 of 43
different vendors handle stack initialization differently. For VirtualKey, the stack initialization is done by a series of settings that cannot be changed by the user. Device Management The Java Bluetooth APIs contains the classes LocalDevice and RemoteDevice, which provide the device-management capabilities defined in the Generic Access Profile (GPA). LocalDevice depends on the javax.bluetooth.deviceclass class to retrieve the device's type and the kinds of services it offers. The RemoteDevice class represents a remote device (a device within a range of reach) and provides methods to retrieve information about the device, including its Bluetooth address and name. The RemoteDevice class also provides methods to authenticate, authorize, or encrypt data transferred between local and remote devices. Device Discovery Because wireless devices are mobile they need a mechanism that allows them to find other devices and gain access to their capabilities. The core Bluetooth API's DiscoveryAgent class and DiscoveryListener interface provide the necessary discovery services. A Bluetooth device can use a DiscoveryAgent object to obtain a list of accessible devices, in any of three ways: The DiscoveryAgent.startInquiry method places the device into an inquiry mode. To take advantage of this mode, the application must specify an event listener that will respond to inquiry-related events. DiscoveryListener.deviceDiscovered is called each time an inquiry finds a device. When the inquiry is completed or canceled, DiscoveryListener.inquiryCompleted is invoked. If the device doesn't wish to wait for devices to be discovered, it can use the DiscoveryAgent.retrieveDevices method to retrieve an existing list. Depending on the parameter passed, this method will return either a list of devices that were found in a previous inquiry, or a list of pre-known devices that the local device has told the Bluetooth Control Center it will contact often. Service Discovery Once the local device has discovered at least one remote device, it can begin to search for available services, which is Bluetooth applications that can be used to accomplish useful tasks. Because service discovery is much like device discovery, DiscoveryAgent also provides methods to discover services on a Bluetooth server device, and to initiate service-discovery transactions. Service Registration Before a service can be discovered, it must first be registered (advertised on a Bluetooth server device). The server is responsible for: Creating a service record that describes the service offered Adding the service record to the server's Service Discovery Database (SDDB), so it's visible and available to potential clients Registering the Bluetooth security measures associated with the service (enforced for connections with clients) Accepting connections from clients Updating the service record in the SDDB whenever the service's attributes change Page 34 of 43
Removing or disabling the service record in the SDDB when the service is no longer available Service Registration Procedure: 1. To create a new service record that represents the service, invoke Connector.open with a server connection URL argument, and cast the result to a StreamConnectionNotifier that represents the service: 2. Obtain the service record created by the server device: 3. Indicate that the service is ready to accept a client connection: 4. When the server is ready to exit, close the connection and remove the service record: Communication For a local device to use a service on a remote device, the two devices must share a common communications protocol. So that applications can access a wide variety of Bluetooth services, the Java APIs for Bluetooth provide mechanisms that allow connections to any service that uses RFCOMM, L2CAP, or OBEX as its protocol. 7.18 Serial Port Profile (SPP) The RFCOMM protocol, which is layered over the L2CAP protocol, emulates an RS-232 serial connection. The Serial Port Profile (SPP) eases communication between Bluetooth devices by providing a stream-based interface to the RFCOMM protocol. Some capabilities and limitations to note: Two devices can share only one RFCOMM session at a time. Up to 60 logical serial connections can be multiplexed over this session. A single Bluetooth device can have at most 30 active RFCOMM services. A device can support only one client connection to any given service at a time. For a server (home appliance) and client (cell phone) to communicate using the Serial Port Profile, each must perform a few simple steps. The server must: Construct a URL that indicates how to connect to the service, and store it in the service record Make the service record available to the client Accept a connection from the client Send and receive data to and from the client The URL placed in the service record may look something like: btspp://102030405060740a1b1c1d1e100:5 This says that a client should use the Bluetooth Serial Port Profile to establish a connection to this service, which is identified with server channel 5 on a device whose address is 102030405060740A1B1C1D1E100. At the other end, to set up an RFCOMM connection to a server the client must: Initiate a service discovery to retrieve the service record Construct a connection URL using the service record Open a connection to the server Send and receive data to and from the server Page 35 of 43
7.19 Typical Use Cases of a Bluetooth-Enabled Application A Bluetooth-enabled application can be either a server or a client, or it can behave as a true peer-topeer endpoint by exposing both server (home appliance) and client (cell phone) behavior. The following figure illustrates an application's Bluetooth-specific use cases: Figure 19: Typical Use Cases of a Bluetooth-Enabled Application 1 These use cases can be summarized as below: Initialization All Bluetooth-enabled applications must first initialize the Bluetooth stack. Client (cell phone) A client consumes remote services, which are the functions of home appliance, such as turn on / off power etc. A client first discovers any nearby devices (home appliances), then for each discovered device it searches for services of interest. Server (home appliance) A server (home appliance) makes services (turn on/off power, open/close door) available to clients (cell phone). A server registers services in the Service Discovery Database (SDDB), in effect advertising them. It then waits for incoming connections, accepts them as they come in, Page 36 of 43
and serves the clients that make them. Finally, when the service is no longer needed the application removes it from the SDDB. 7.20 Establishing a Network Connection When a device is not connected to a piconet, it is in a standby mode. In this mode, the device listens for messages every 1.28 seconds over 32 hop frequencies. When one device wishes to establish a connection with another, it sends out 16 identical page messages on 16 hop frequencies. If the slave doesn't respond, the master retransmits the page message on the other 16 hop frequencies. If the master doesn't know the slave's address it must precede the page message with an inquiry message, which requires an extra response from the slave unit. When the slave responds to the page message, the master can begin transmitting voice or data. The following procedures demonstrate accessing the network connection between cell phone and Virtualkey product. These procedures are carried out automatically in the cell phone: 1. Inquire: In a new environment, the device automatically initiates an inquiry to find an access point. All nearby access points respond with their addresses, and the device picks one. 2. Page: The paging procedure synchronizes the device with the access point. 3. Establish a link: The Link Manager Protocol establishes a link with the access point. 4. Discover services: The LMP uses the Service Discovery Protocol (SDP) to find out what services are available from the access point. Here we assume that the email service is available. 5. Create an L2CAP Channel: The LMP uses information obtained from the Service Discovery Protocol (SDP) to create an L2CAP channel to the access point. The application may use this channel directly or use a protocol like RFCOMM (Radio Frequency Communications Protocol) that might be running over L2CAP. RFCOMM emulates a serial line. 6. Create an RFCOMM channel: Depending on the needs of the application, an RFCOMM channel (or another channel) is created over the L2CAP channel. Creating an RFCOMM channel allows an existing application that works with serial ports to work with Bluetooth as well, without any modifications. 7. Authenticate: This is the only step that requires input from the user. If the access point requires authentication, it will send an authentication request, and the user will be prompted to enter a PIN to access the service. For security reasons, the PIN code itself is not sent over the wireless link, but rather a key generated from it. 8. Log in: If the devices use the Point-to-Point Protocol (PPP) over RFCOMM, a serial port is emulated, and Sally can log in to her email account. 9. Send and receive data: The email client and the access point now use standard network protocols like TCP/IP to send and receive data. The following diagram shows the typical activities of Bluetooth client (cell phone) and server (home appliance) applications: Page 37 of 43
Figure 20: Server and Client Activities 1 Page 38 of 43
In the above figure, both client and server perform initialization; the server application prepares a service and waits for connections; the client discovers devices and services, and then connects to specific device to consume a particular service. 7.21 Discovering Devices and Services Figure 21: Discovering Devices and Services 1 A client can't consume services until it finds them. The search cycle consists of discovering nearby devices, then for each discovered device searching for services of interest. Discovering devices, Page 39 of 43