wireless communication bluetooth technology

ABSTRACT


Bluetooth technology is a short range wireless protocol which designed to create
adhoc networks. The Bluetooth was invented by L.M.ericsson in 1994. It operates
in industrial,scientific and medical(ISM) band of electromagnetic spectrum.
The major advantages of Bluetooth are:
• Low cost
• Low complexity(for user)
• Low power consumption
• Easy synchronization.
The Bluetooth applications are based on different protocols.the different protocols
are as follows:
OBEX (object exchange protocol):
• Sending and receiving files.
• Remotely browsing and accessing files
RFCOMM:
• Serial port emulation
• Data stream
L2CAP:
• Segments and reassembles data packets between higher level protocols and HCI
• Multiplexes data from higher level protocols
• A fundamental protocol for accessing most Bluetooth applications.
The main aim of Bluetooth technology is to provide low cost wireless communication and provide a better technology for the people.

INTRODUCTION:

Being human beings, we have the greatest ability to communicate in an effective manner. If we speak or write according to a pre-defined set of linguistic rules, we will succeed in conveying information to others. The tools of human communication, producing sounds that are perceived as speech or creating words on a page, once learnt are used without thought. The limitation on these physical processes that we take for granted is the actual translation of thoughts into effective and meaningful statements. When it comes to electronic communication, however, there is very little that can be assumed or taken for granted. Communication between electronic devices can only be achieved when they also abide by a set of predetermined rules and standards—the Open Systems.

Interconnect (OSI) model for communications systems protocol stacks being the primary example, and the basis from which many others have evolved. These standards need to be applied to every aspect of the communication process, from the manipulation of data at the highest level to the utilization of physical transmission media at the lowest. Electronic communication has evolved significantly over the last decade from the earliest packet switched data networks. New technologies are now emerging that allows wireless communication. We are now in search of that kind of communication which is the means to create wireless, low-power, cost-effective, unconscious and ad-hoc connectivity between our devices. Its name: Bluetooth the jokes, but in reality we can utilize this technology now to develop products that will allow us to throw away all the wires .Excellent, we all think, and our imagination races into the realms of Science. Fiction, removing the wires from everything! Musing on using our mobile phone to communicate and control everything the same way we use the TV remote to operate our entertainment systems. After going through the fore coming data we are sure that you will be confident that Bluetooth technology is right for you.

Why Throw Away Wires?

Wired or wireless?
Let’s examine just why we would want to connect without wires, and what it might offer us in tangible terms; we can use the paradigm of our own Personal Area Network (PAN).We have a PC with its ubiquitous mouse and keyboard, a laptop, a Personal Digital Assistant (PDA), a mobile phone with a “hands free” kit and a printer. How do we currently communicate between these devices? The answer is: with a rather unwieldy network of cables, hubs, and connectors, plugging, unplugging, and synchronizing often with the compulsory intervention of the overworked and often less-than-friendly IT department.

Figure 1.1 - A Bluetooth PAN “Does not Include Power Cables to PC and Printer” connecting Headset Cellular, Phone, PDA, Laptop, Mouse, Printer.

Figure 1.1 illustrates the alternative scenario to Bluetooth-enable all of these devices. The simple act of utilizing Bluetooth technology as cable replacement removes the problem of the actual physical connections and the unconscious and ad-hoc connection capability of the technology can allow communication between the devices with no user intervention at all (OK, after some software configuration and initial device setup!).This fully wireless scenario can be achieved because of the master/slave nature of the Bluetooth technology. All devices are peers, identified by their own unique 48-bit address, and can be assigned as a master either by function or user intervention. A master can connect to up to seven slaves at the same time, forming a piconet—this “point-to-multipoint” feature is what sets Bluetooth apart from other wireless technologies.


Figure 1.2 - Bluetooth Technology Connection Scenarios (Personal connection, Point to Point, point to Multipoint)


Figure 1.3 – Bluetooth Scatternet scenario.

In the ultimate scenario, a member of one piconet can also belong to another piconet. Figure 1.3 illustrates the scatternet, wherein a slave in one piconet is also the master of a second piconet, thus extending the networking between devices. A device in my PAN can communicate with one in yours!
Let us put this into context by interpreting exactly what “unconscious and ad-hoc connections” can mean to us in real life, and how the fundamental components of the Bluetooth PAN in Figure 1.1 can be integrated into a wireless infrastructure to enhance our lives and even reduce the need to queue!

ALLOWING FOR INTERFERENCE:

Wireless means a radio link—and radio links are subject to interference. Interference can impact both the quality of an audio (Synchronous Connection Oriented [SCO]) connection or the throughput of a data (Asynchronous Connectionless [ACL]) connection. High levels of interference can interrupt communications for long enough to cause the protocol stack to timeout and abandon the link altogether. Although this is addressed in the Bluetooth Specification with a frequency-hopping scheme which does provide robustness, it is still a serious consideration for some applications. Bluetooth technology should not be used for safety-critical applications where data absolutely must get through, because there is always a possibility of a burst of interference stopping the link. Interference can come from a variety of sources: microwave ovens, thunderstorms, other communications systems (such as IEEE 802.11b), even other Bluetooth devices in the area (although these will not have a great effect as they are designed to cope with interference from one another in normal use).

It is possible to overcome the problem of link failure. For example, if you are relying on a Bluetooth link to monitor your baby and you know the environment is such that the link will only fail approximately once a week, then you might be happy to have the receiver alert you when the link fails. Once a week you may be out of touch, but an alert will let you know that the link has failed, so you have the option of returning within earshot of the infant. Since the Bluetooth links only operate up to around 100 meters, it shouldn’t take you too long to get there!

There are other safety-critical applications where an unreliable link may be acceptable. An example is a system developed for Nokian tires, which allows tire pressure to be automatically monitored and sent to the car dashboard display. A wireless link will be subject to frequent failures in the harsh automotive environment, but the link can be re-established. Even if it only works a tenth of the time, it is still checking tire pressures far more often than will the average motorist!

Here again, the system could be set to alert the driver if the tire pressures have not been reported recently. This way the driver knows that a manual check is needed. So far, we have looked at effects of the Bluetooth link receiving interference, but, of course, it can also interfere with other devices. There are two delays in setting up a Bluetooth link. First, it takes time to discover devices in the neighborhood. In device discovery, a device sends out inquiry packets, and receives responses from devices in the area, then reports these to the user. It can take ten seconds to find all the devices in an area, and even then you will only find those devices which are willing to report their presence. Some devices may not be set to scan for inquiries, in which case you will never find them!

A second delay occurs when you set up the connection itself. Again, this can take up to ten seconds. This lengthy connection time means that Bluetooth devices are unsuitable for systems where a fast response is needed, such as automatic toll collection on busy roads. Coping with Limited Bandwidth Wireless can also mean “slower.” An Internet connection via a Bluetooth LAN is limited to the maximum data rate (723.2 Kbps) over the air interface. After allowing for management traffic and the capacity taken up by headers for the various protocol layers, even less is available to applications at the top of the stack. This will not compete with a high-speed wired link. Thus, for sending or downloading vast amounts of data, a Bluetooth wireless connection would not be the optimum method.

CONSIDERING PRODUCT DESIGN:

Your product may look like a candidate Bluetooth product, but there are practical considerations to take into account. It costs money to add a Bluetooth link, and for some products, that cost may be more than the customer is willing to pay. You must look long and hard at the design of your product, how Bluetooth technology will affect the design, and whether in the final analysis that cost will be worth it. some specifications should be taken in to account when moving from a wired product to a wireless one.
Let’s examine the traditional headset and mobile phone and decide if Bluetooth technology makes this more convenient for the user. With current hands-free technology, you have to decide in advance if you require the hands free option. This involves fitting your car with a hands-free kit—a microphone or headset plugged in, with the wire trailing from it to your phone which is either in your pocket, clipped to your jacket/belt, in a cradle on your dashboard, or like most of us, fallen down between the seat and the handbrake!

When you receive a call, you answer by pressing a button on the cable; volume control is available via a button on the cable.The limitation is that you always have to have your telephone with you; it can only be as far away as the cable is long.Thus, it is always a conscious decision to use the headset, and to decide to plug it in! With a Bluetooth headset and phone, the phone can be inside your briefcase, in the boot of the car, in your jacket on the hook in the office, in fact, absolutely anywhere—as long as it’s within the range of the headset. In much the same way as the conventional technology, you press a button on the headset to receive a call or to adjust the volume.The connection between the two devices is extremely different, however, and although virtually invisible to the user, it will incur a connection time overhead.
First, the headset must “pair” with the Audio Gateway (AG), the Bluetooth part of the phone.This allows Bluetooth addresses to be swapped, and link keys to be established.The headset will then be able to make a connection to the AG or the AG will be able to connect to the headset—the exact operation is a software application issue. If the headset connects to the phone, then the phone needs to know why, either to set up voice dialing, action voice dialing, or some other function. If the phone connects to the headset, it patches a SCO link across and the headset can be used to take the incoming call.
The connection time could be a problem if you must connect every time a call comes in. After ten seconds of trying to make a connection, the caller has probably decided you are not going to answer and given up! A low power park mode allows headset and phone to stay constantly connected without draining their batteries; this overcomes the slow connection problem. So you must beware if connection time is an issue for your product, make absolutely sure your system supports park mode although it’s becoming increasingly common, it’s still possible to buy devices that do not support it.
My conclusion would be that Bluetooth technology would make answering my phone far more convenient, although extremely expensive at the moment! I do not have to worry where my phone is, per-equip my car, or have to endure cable running from my ear. If the complex connection issues are invisible to me and I look as cool as Lara Croft (she wore the original Ericsson Bluetooth headset in the Tomb Raider movie), who really cares! However if it turns into a software setup nightmare and I have to read through vast user guides, I would not be so sure.
Bluetooth piconets are highly dynamic—they change rapidly, with devices appearing and disappearing. The members of a piconet may change, or the whole piconet may be dissolved in a moment. In such a dynamic network, it is not viable to spend significant time acquiring information about devices and configuring software to use them: this process must be automatic. The Bluetooth core specification provides this automatic discovery and configuration. For a Bluetooth device, the steps to using a new device are:

• Perform device discovery to find devices in the area.
• Perform service discovery to get information on how to connect to services on each device
discovered.
• Choose a service to use, and use information obtained during service discovery to connect to it.
ww.syngress.com
Potentially, the user could simply select the option to print, and the processes of device discovery, service discovery, and connection could happen automatically without further intervention from the user. The application software should present this to us transparently, but it is still a worthwhile exercise to understand the complete procedures; they are covered in the following sections.

DISCOVERING DEVICES:

Before any two devices can go through device discovery, they must be in inquiry and inquiry scan modes. The inquiring device must be trying to discover neighboring devices, and the inquiry scanning device must be willing to be discovered (Figure 1.4). The inquiring device transmits a series of inquiry packets. These short packets are sent out rapidly in a sequence of different frequencies. The inquiring device changes frequencies 3200 times a second (twice the rate for a device in a normal connection).This fast frequency hopping allows the inquirer to cover a range of frequencies as rapidly as possible. These packets do not identify the inquiring device in any way; they are ID packets containing an inquiry access code which inquiry scanning devices will recognize.


Figure 1.4 - Bluetooth Device Discovery
Figure 1.4 illustrates the detection of modes of different devices following :
“I am in inquiry scan mode”
“I am in inquiry scan mode”
“I am in inquiry mode”
Inquiry
“Inquiry response”
Inquiry
“Inquiry response”
“I see a phone and a PDA”
“Investigating interference”

The Bluetooth system operates in the 2.4GHz band. This band is known as the Industrial Scientific and Medical (ISM) band. In the majority of countries around the world, this band is available from 2.40–2.4835GHz and thus allows the Bluetooth system to be global. It is available for free unlicensed use in most of the world, although some countries have restrictions on which parts of the band may be used. However this freedom has a price many other technologies also reside in the band:
• 802.11b
• Home RF
• Some Digital Enhanced Cordless Communications (DECT) variants
• Some handheld short-range two-way radio sets (walkie-talkies)
These are all intentional emitters, one way or another function is to generate microwave radiation in the ISM band. In addition to the intentional emitters, Bluetooth technology is subject to interference from a variety of sources which emit accidentally:
• Microwave ovens
• High-power sodium lights
• Thunderstorms
• Overhead cables
• Com Communications channels in other bands—e.g., GSM, CDMA
• Spark generators such as poorly suppressed engines
www.syngress.com
There are also problems from signal fading due to distance or blockers such as walls, furniture, and human bodies. The more water content in the object, the more significant the effect of blocking. Old brick walls will have a higher water concentration than modern ones due to the nature of their constitution. This tends to cause fading in European houses where brick is a common construction material.

ENABLING SECURITY:

To prevent unwanted devices connecting to our personal devices, or to prevent our personal data from being “snatched” from the air. Bluetooth technology provides security in the form of a process called pairing. w.syngress.com



Figure 1.5 - Interfering Piconets
Figure 1.5 illustrates the following :
Class 1 Slave
Class 3 Slave
Class 2 Slave
Class 1
Master
Class 1 Slave
Class 1 Slave
Class 3 Slave
Class 3 Slave
Class 2 Slave
Class 2 Slave
Class 2 Master
Class 3 Master
Class 2 Master
Class 3 Slave Class 3 Slave

INTRODUCING BLUETOOTH APPLICATIONS:

Encryption engine, using up to 128-bit keys. How this provides us with the means to “pair” with another selected device and create a secure link is interesting. It is possible to “authenticate” a device this allows a pair of devices to verify that they share a secret key. This secret key is derived from a Bluetooth pass key or Personal Identification Number (PIN).The PIN is either entered by the user or, for devices with no MMI (such as a headset), it will be programmed in at manufacture. After the devices have authenticated, they are able to create shared link keys which are used to encrypt traffic on a link. This combination of authentication and link key creation is called pairing. Pairing devices allows communication secure from eavesdropping, but enabling security can make it much more difficult to connect with other people’s devices, thus security features can seriously compromise usability. For devices where disabling security may be appropriate, the user interface should allow security to be turned on and off simply.

CHOOSING A SYSTEM SOFTWARE ARCHITECTURE:

The choice of system architecture will obviously be determined by footprint, cost, and time-to-market, but the end functionality will have the biggest influence. We will briefly examine the Bluetooth protocol stack as it can have an influence on our product’s system architecture. We will examine the stack in its simplest form the upper stack and the lower stack. The lower stack controls all of the physical functionality, the radio, the baseband, and the Link Manager (LM) and Link Controller (LC) layers. The upper stack deals with the channel multiplexing, with the logical link control and adaptation protocol (L2CAP). Serial port emulation and the interface with the application software happens in the RFCOMM layer.

Discovery Protocol (SDP) layer is also essential for all Bluetooth devices, as it
allows them to find out about one another’s capabilities—an essential facility when you are forming ad-hoc connections with devices you may never have seen before. There are three implementation models for the stack, dependant upon the functionality or resources the respective product has: hosted, embedded, and fully embedded (Figure 1.6)


Figure 1.6 Software Stack Implementations



REVIEWING THE PROTOCOL STACK:

The wide range of possible Bluetooth applications means that there are many Bluetooth software layers. The lower layers (Radio Baseband, Link Controller, and Link Manager) are very similar to the over-air transmissions. They can provide voice connections and a single data pipe between two Bluetooth devices.To ease integration of Bluetooth into existing applications, the specification provides middle layers that attempt to hide some of the complexities of wireless communications.

In combination, these layers, when transmitting, can take many familiar data formats and protocols, package them, multiplex them together, and pass them on in a manner that matches the lower layers’ capabilities. Matching layers at the receiving end de-multiplex and un-package the data. At the bottom of the stack are some layers that are fundamental to Bluetooth wireless technology: Radio Baseband, Link Manager, Logical Link Control and Adaptation Protocol (L2CAP), and Service Discovery Protocol (SDP).Above these layers, different applications require different selections from the higher layers. Each profile calls up the higher layers it requires. If you implement more than one profile in your application, you may be able to reuse the common layers. Not all stack vendors support all layers so, if you are buying in a stack,make sure that it supports the layers required for your application’s profiles. Figure 2.1 shows the layers defined by the Bluetooth specification (shown unshaded) and some other common layers (shown shaded).

L2CAP (Logical Link Control and Adaptation Protocol):
Logical Link Control and Adaptation Protocol not necessarily match the CID used by the remote device to identify the other end of the same channel. CIDs 0x0000 to 0x003F are reserved with 0x0000 being


Figure 1.7 - Bluetooth Protocol Stack

RFCOMM (a name coming from an Radio Frequency [RF]-oriented emulation of the serial COM ports on a PC) emulates full 9-pin RS232 serial communication over an L2CAP channel. It is based on the TS 07.10 standard for a software emulation of the RS232 hardware interface.TS 07.10 includes the ability to multiplex several emulated serial ports onto a single data connection using a different.
m
RELIABILITY OF L2CAP:

Because of the nature of wireless communications, the links provided by the baseband are not reliable. Errors are caused by radio interference or fading of signals. There is a chance that two or more errors in a packet will combine to give a packet that contains errors but still has a correct checksum. The Bluetooth Special Interest Group (SIG) is considering implementing error correction at L2CAP, which would make such errors less likely to affect applications.

Data Link Connection Identifier (DLCI) for each port. However, each TS 07.10 session can only connect over a single L2CAP channel and thus only communicate with one device. A master device must have separate RFCOMM sessions running for each slave requiring a serial port connection. Version 1.1 of the Bluetooth specification has added to the capabilities of the standard TS07.10 specification by providing flow control capabilities. This caters for mobile devices with limited data processing and storage capabilities allowing them to limit the incoming flow of data.
OBEX:

The Object Exchange standard (OBEX) was developed by the Infrared Data Association (IrDA) to facilitate operations common to IR-enabled devices like personal digital assistants (PDAs) and laptops. Rather than develop a new standard, the Bluetooth SIG took OBEX largely as is, detailed a few specifics regarding Bluetooth implementation (e.g., making some optional features mandatory), and used it in the File Transfer, Synchronization, and Object Push profiles.
OBEX allows users to put and get data objects, create and delete folders and objects, and specify the working directory at the remote end of the link. IrDA has also provided formats for data objects, while the Bluetooth specification has adopted the vCard format for business card exchange and the vCal format for exchanging calendars.

PPP:

The Point-to-Point Protocol (PPP) is the existing method used when transferring Transmission Control Protocol/Internet Protocol (TCP/IP) data over modem connections. The Bluetooth specification reuses this protocol in the local area network (LAN) Access Profile to route network data over an RFCOMM port. Work is already underway on a TCP/IP layer that will sit directly above L2CAP, bypassing and removing the overhead of PPP and RFCOMM.This work is hinted at in some areas of the specification, but in v1.1 PPP, is all that’s available.

TCS Binary:

Telephony Control Protocol Specification Binary (TCS Binary, also called TCSBIN), is based on the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Q.931 standard for telephony call control. It includes a range of signaling commands from group management to incomingyncall notification, as well as audio connection establishment and termination. It is used in both the Cordless Telephony and Intercom profiles.

SDP:

The Service Discovery Protocol differs from all other layers above L2CAP in that it is Bluetooth-centered. It is not designed to interface to an existing higher layer protocol, but instead addresses a specific requirement of Bluetooth operation: finding out what services are available on a connected device. The SDP layer acts like a service database. The local application is responsible for registering available services on the database and keeping records up to date. Remote devices may
then query the database to find out what services are available and how to connect to them. The details of service discovery can be complex and are discussed further in Chapter 5, but each profile describes exactly what information should be registered with SDP based on the application implementation.
Management Entities Device, Security, and Connection Managers are not protocol layers so much as function blocks. The Device Manager handles the lower level operation of the Bluetooth device. The Connection Manager is responsible for coordinating the requirements of different applications using Bluetooth channels and sometimes automating common procedures. The Security Manager checks that users of the Bluetooth services have sufficient security privileges.

HCI:

The Host Controller Interface is not a software layer, but a transport and communications protocol that aids interoperability between different manufacturers’ solutions. It is not mandatory to use the HCI interfaces defined in the specification (Universal Serial Bus [USB]; RS232; or a simple Universal Asynchronous Receive Transmit [UART]), or indeed any HCI transport at all, if there are better solutions for your application.

Lower Layers:

The lower layers (Radio Baseband, Link Controller, and Link Manager) format the over-air transmissions, handle error detection and re-transmission, and manage the links between devices.
www.syngress.com

Masters, Slaves, Role Switches, and Scatter nets:

To upper stack layers, the only difference between a master and a slave is that a master can talk to several slaves in a piconet, while a slave can only talk to the master of the piconet. For some devices, this relationship is important. Take, for example, a PC with a Bluetooth mouse and keyboard already operating. The PC may also wish to allow a PDA to connect and synchronize. Since the PDA initiates the connection, it becomes the master of the new piconet, but the PC will only have allowed this connection if, as part of the connection request, the PDA stated it allows master/slave role switches. As soon as the connection is established at baseband level, the PC requests a switch. If the PDA does not grant it, the PC drops the connection. Interestingly, for the time between the connection completing and the role switch taking place, the PC is still master of its old piconet even though it’s a slave of the PDA’s piconet. When a single device is a master of one piconet, and slave of another simultaneously, this is, by definition, a scatternet. Several manufacturers now support the limited form of scatternet required for a master/slave role switch while master of an existing piconet, but maintaining the scatternet for any length of time is still problematic.

The Bluetooth specification gives no way for a slave to demand hold, sniff, or park modes from a master; they must always be requested. The master is entitled to refuse such requests, so it is impossible to guarantee that a slave in one piconet will be granted the time required to participate in another piconet as a master or a slave. Even if devices choose to simply switch between piconets as they see fit, ignoring the normal request procedures, there are still problems with how to time these switches in order to maintain multiple connections. The master of each piconet must periodically poll all its slaves in order to give them an opportunity to transmit (since slaves only transmit data in response to a master transmission). How to cope with the variability of the interval between poll transmissions from a master is particularly awkward. It is possible to devise solutions to these problems, but there are a number of possible solutions and no guarantee that two implementers will choose the same one.
A single chip set vendor may be able to demonstrate scatternet operation provided they produce all devices in the scatternet, but this provision goes against the fundamental Bluetooth concept of interoperability. Work is progressing in the Bluetooth SIG to devise a standard solution to these problems.There is an even greater problem with SCO connections in a scatternet, however. The reserved slots for SCO connection in two scatternet connected piconets are running on different clocks. They will eventually drift, relative to each other, so that the reserved slots coincide, making it impossible for a single device to be part of both piconets. There is no way to renegotiate the SCO timing once the link has been set up. Fortunately, the problems with ACL scatternets may be resolved soon, but those of SCO scatternets will likely be around for a very long time. For the moment though, no profiles use, let alone require, scatternet operation.



Who Calls Who?

Many Bluetooth profiles don’t care which device is the master of a link and which is a slave. For a Point-to-Point Profile, the distinction is meaningless at the higher layers. However, the distinction should be considered, especially for battery-powered devices, as it can have a huge effect on a device’s power consumption, for two reasons.

Take, for example, a PDA that wishes to periodically and unconsciously synchronize with a PC. Firstly, if by default, the PC initiates connections, then the PDA must be connectable at all times. Even with an average Page Scan current draw of 0.5 mA, it is still going to use 12 mA-hours of power per day just maintaining the Page Scan mode. It may be more efficient to have the PDA wake periodically and attempt to page the PC.

Secondly, although a slave can request power saving modes such as sniff and park, a master is under no obligation to grant them. If they are not granted, then a slave must listen for a master’s transmissions in every possible transmit slot, draining power each time. As a master, a device only needs to transmit enough to maintain a link and there is a better chance that power saving modes can be negotiated and used.





CONCLUSION:

• A new global standard for data and voice
• Eliminate cables
• Low power,Low range,Low cost networks devices
• Develops automatic synchronisity between devices.