07-06-2010, 08:10 PM
[attachment=3723]
A Paper Presentation on BLUETOOTH TECHNOLOGY IN WIRELESS COMMUNICATIONS
at
TECHFEST 2005
(A NATIONAL LEVEL TECHNICAL STUDENT PAPER PRESENTATION CONTEST)
Presented By
ARIF M. JEELANI P. SIVA NAGENDRA RAO
02481A0411 02481A0453
III / IV E.C.E
Gudlavalleru Engineering College,
Gudlavalleru.
Krishna district,
AP “ 521 356
Abstract:
Imagine the world with out wires and cables. Is this possible Yes this can be possible with the implementation of a new technology in wireless communication called BLUETOOTH TECHNOLOGY.
Bluetooth is a method for data communication that used short-range radio links to replace cables between computers and their connected units. Industry-wide Bluetooth promises very substantial benefits for wireless network operations, end workers and content developers of exciting new applications. This article delves into the implementation and architecture of Bluetooth. It also describes the functional overview and applications of Bluetooth, and deals with the development of a model for recording, printing, monitoring, and controlling of eight process variables at the same time, using a distributed control system. We explain industrial automation via Bluetooth using IISS. Industrial automation is one of the major applications of Bluetooth technology. Industrial automation, in terms of controlling or monitoring a factory. Office or industrial process means to install machines that can do the work instead of human workers. Industrial plants consists of many devices interconnected in different ways ranging from simple data collection units (I/O) to more intelligent devices such as sensor, one-loop controllers, or programmable controls, and a supervisory system used as a human-machine interface (HMI) for data logging and supervisory control. As IISS is a controlling device that monitors the devices in a company. It basically communicates via the interface card in the PC; the hardware is connected parallel across the device, and it is interfaced with the PC via a transceiver. The device can be accessed both manually via the switches and remotely via the PC. A simulation of connecting a PC withy the machines in a company was executed. Also, we wrote a software program using C language; we will show the remote monitoring takes place between the control room and the PC. These details in the article establish the growing need for Bluetooth technology.
Introduction:
Bluetooth is an open standard for wireless connectivity with supporters mostly from the PC and cell phone industries. Not surprisingly, it primary marker is for data and voice transfer between communication devices and PCs. In the way, it is similar in purpose to the IrDA protocol, Bluetooth, however, is a radio frequency (RI) technology utilizing the unlicensed 2.5 GHz industrial, scientific, and medical (ISM) band. Target applications include PC and peripheral networking, hidden computing, and data synchronization such as for address bookstand calendars. Other applications could include home networking and home applications of the future such as smart appliances, heating systems, and entertainment devices.
Bluetooth history:
Bluetooth was invented in 1994 by L.M. Eriesson of Sweden. The standard is named after Harald Blaatand Bluetooth II. King of Denmark 940-9SIAD. A nice stone has be received in his capitol city Jelling (Jutland) that depicts the chivalry of Harald and the Ëœruncesâ„¢ say
Harald christianized the Danes.
Harald controlled Denmark and Norway.
Harald thinks and cellular phones should seamlessly communicate.
The blue tooth Special Interest Group (SIG) was founded by Ericsson. IBM. Intel. Nokia and Toshiba in February 1998 to develop as open specification for short-range wireless connectivity. The group is now also promoted by 3 Com. Microsoft. Lucent and Motorola. More than 1900 companies have joined the SIG.
The following section describes some of the requirements for the Bluetooth system and in essence suggests the functionalities planned for it.
Why Bluetooth
Bluetooth attempts to provide significant advantages over other data transfer technologies, such as Ir DA and Home RF, vying for similar markets. Despite comments from the Bluetooth SIG indicating that the technology is complementary to Ir DA it is clearly a competitor for PC-to peripheral connection, Ir DA is already popular in PC peripherals, but is severely limited by the short connection distance of 1 m and the line-or-sight requirement for communication. This limitation laminates the feasibility of using Ir DA for chidden computing, where the communicating devices are carboy but not visible to one another.
Due to its RF nature, Bluetooth is not subset to such limitations. In addition to wireless device connections up to 10m (up to 100 m if he transmitterâ„¢s power is increased), devices used not be within line of sight and may even connect through walls or other nonmetal objects. This allows for applications such as a cell phone in a pocket or a briefcase acting as a modem for laptop or PDA.
Bluetooth is designed to be low cost, inventorially under $ 10/unit. On the flip side, however, are the limited connection distance and, even more damaging, the transmission speeds. Bluetooth supports only 780 kb/s, which may be used for 721 kb/s unidirectional data transfer (57.6 kb/s return direction) or up to 432.6 kb/s symmetric data transfer. These rates are comparable to the 1 “ 2 Mb/s supported by Home RF and. Although live digital video is still beyond the capability of any RF technology, perfectly adequate for file transfer and printing applications.
Finally, Blue toothâ„¢s main strength is its ability to simultaneously handle both data and voice transmissions. It is capable of supporting on asynchronous data channel and up to three synchronous voice channels, or one channel supporting both voice and data. This capability combined with ad hoc device connection and automatic service discovery make it a superior solutions for mobile devices and Internet applications. This combination allows such innovative solutions as a mobile hands-free headset for voice calls, print to fax capability, and automatically synchronizing PDA, laptop and cell phone address book applications.
Architecture Overview
Bluetooth page link control hardware, integrated as either one-chip o a radio module and a base-band module, implements the RF, base-band, and page link manager portions of the Bluetooth specifications. This hardware handles radio transmission and reception as well as required digital signal processing for the base band protocol. Its functions include establishing connections, support for asynchronous (data) and synchronous (voice) links, error correction, and authentication. The page link manager firmware provided with the base band CPU performs low-level device discovery, page link setup, authentication, and page link configuration. Link managers on separate devices communicate using the Link Management Protocol, which utilizes the services of the underlying page link controller (base band). The page link control hardware may also provide a host controller interface (HCL) as a standard interface to the software.
Wireless signal
HCL
HCL Firmware
Transport
Network Topology:
Bluetooth devices are generally organized into groups of two to eight devices called Pico nets. Consisting of a single master device and one or more slave devices. A device may additionally belong to more than one piconet, either as a slave in both or as a master of one piconet and a slave in another. These bridge devices effectively connect Pico nets into a scatter net. A diagram of a blue tooth scatter net.
Bluetooth operates in the unlicensed ISM frequency band, generally cluttered with signals from other devices; garage door openers, baby monitors, and microwave ovens, to name just a few. To help Bluetooth devices coexist and operate reliably alongside other IMS devices each Bluetooth piconet is synchronized to a specific frequency-hopping pattern. This pattern, moving through 1600 different frequencies per second, is unique to the particular piconet. Each frequency hop is a time slot during which data packets are transferred. A packet may actually span up to five time slots, in which case the frequency remains constant for the duration of that transfer.
Baseband State Machine:
Piconets may be static or formed dynamically as devices move in and out of range of one another. A device leaves standby (the low-power default state) by initiating or receiving an inquiry or a page command. An inquiry may be used if the address of a targeted device is unknown; it must be followed by a page command. A page command containing a specific Device Access-Code is used to connect to a remote device. Once the remote device responds, both devices enter the connected state, with the initiating device becoming the master and the responding device acting as a slave.
One in the connected state, the slave device will synchronize to the masterâ„¢s clock and to the correct frequency-hopping patterns. At this point, page link managers exchange commands in order to set up the page link and acquire device information. The master will then initiate regular transmissions in order to keep the piconet synchronized. Slaves listen on every master-transmit time slot in order to synchronize with the master and to determine if they have been addressed.
Each active slave is assigned an active member address (AM_ADDR) and participates actively on the piconet, listening to all master time slots to determine if it is being addressed by the master. In addition, there are three lower-power slave states: sniff, hold, and park. A master can only transmit to devices in sniff mode during particular sniff-designated time slots. Therefore, these devices listen only during these special time slots and sleep the rest of the time. A slave in hold mode, alternately, does not receive any asynchronous packets and listens only to determine if it should become active again. Finally, a device in park mode not only stops listening, but also gives up its active member address. It is only a member of the piconet in that it remains synchronizing with the frequency-hopping pattern.
Baseband Links:
The Bluetooth base band provides transmission channels for both data and voice, and is capable of supporting on asynchronous data page link and up to three synchronous voice links (or one page link supporting both). Synchronous connection-oriented (SCO) links are typically used for voice transmission. These are point-to-point symmetric connections that reserve tome slots in order to guarantee timely transmission. The slave device is always 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 can support only two SCO links to different masters. SCO packets are never retransmitted.
Asynchronous connectionless (ACL) links are typically used for data transmission. Transmissions on these links are established on a per-slot basic (in slots not reserved for SCO links). ACL links support point-to-multipoint transfers of either asynchronous or isochronous data. After an ACL transmission from the master, only the addressed slave device may respond during the next time slot, or if no device is addressed the packet is considered a broadcast message. Most ACL links include packet retransmission.
Link Manager:
The base band state machine is controlled largely by the page link manager. This firmware, generally provided with the page link control hardware, handles page link setup, security and control. Its capabilities include authentication and security services, quality of service monitoring, and base band state control. The page link manager controls paging. Changing slave modes, and handling required changes in master / slave roles. It also supervises the page link and controls handling of multislot packets.
Link managers communicate with each other using the Link Management Protocol (LMP) which uses the underlying base band services. L.M.P packets, which are sent in the ACI. Payloads are differentiated from logical page link control and adaptation protocol (L2 CAP) packets by a bit in the ACL header. They are always sent is a single-slot packet and are higher priority than L2CP packets. This helps ensure the integrity of the page link under high traffic demand.
Software Protocols:
The remaining Bluetooth protocols implemented in software. L2CAP, the lowest layer provides the interface to the page link controller and allows for interoperability between Bluetooth devices. It provides protocol multiplexing, with allows support for many third-party upper-level protocols such as TCP and a card / volts. In addition. L2CAP provides gr4oup management mapping upper protocol groups to Bluetooth Pico nets, segmentation and reassembly of packets between layers, and negotiation and monitoring quality of service between devices.
Several Bluetooth protocols interface to the L2CAP page link layer. SDP provides service discovery specific to the Bluetooth environment will out inhibiting the used to map the communication AP1 to RFCOM service, effectively allowing legacy software to operate on a Bluetooth device. Technology Control protocol specification (TCS) is provided for voice and data call control, providing group management capabilities and connectionless TCS. Which allows for signaling unrelated to an ongoing call. Blue point-to-point and point-to-multipoint signaling are supported using L2CAZP channels, although actual voice or data is transferred directly to and from the base band-bypassing L2cap-over SCO links.
Bluetooth also supports Ir DA object exchange protocol (IrOBEX) a session protocol defined by IrDA. This protocol may run over other transport layers, including RFCOMM and ICP/IP. For Bluetooth devices. Only connection printed OBEX is supported. There application profiles have been developed using OBEX. These include synchronization functionality for phone books, calendars, messaging and so no; file transfer functionality; and object push for business card support.
Finally Bluetooth may be used as a wireless application Protocol (WAP) bearer. The specification outlines the interoperability requirements for implementing this capability.
Logical Control and Adaptation Protocol:
The L2CAP page link layer operates over an ACL page link provided by the base band. A single ACL link, set up by the page link manager using LMP, is always available between the master and any active slave. This provides a point-to-multipoint page link supporting both asynchronous and isochronous data transfer. L2CAP provides services to upper-level protocol by transmitting data packets over L2CAP channels. Three types of L2CAP channels exist: bi-directional signaling channels that carry commands; connection “ oriented channels for bi-directional point to “ point connections. And unidirectional connectionless channels that support point “ to “multipoint connections, allowing a local L2CAP entity to be connected to a group of remote devices.
Channels:
Shows L2CAP entities with various types of channels between them. Every L2CAP channels includes two endpoints referred to by a logical channel identify (CID). Each CID may represent a channel endpoint for a connection oriented channel, a connectionless channel, or a signaling channel. Since bi-directional signaling channels is required between any two L2CAP colitis before communication can take place, every L2CAP entity will have one signaling channel endpoint with a reserved CID of ox0001. all signal channels between the local L2CAP entity and any remote entities use this one endpoint.
Each connection-oriented channel in an L2CAP entity will have a local CID that is dynamically allocated. All connection-oriented CIDs must be connected to a single channel, and that channel must be configured before data transfer can take place. Notice that the channel will at that point bound to a specific supper level protocol. In addition, an quality of service (QoS) agreement for the channel will be established between the two devices. QoS is negotiating for each cannel during configuration and includes data flow parameters such as peak bandwidth. As well as the transmission type: best effort, guaranteed, or no traffic.
Connectionless channels are unidirectional and used to form groups. A single outgoing connectionless CID on a local device may be logically connected to multiple remote devices. The devices connected to this outgoing endpoint from a logical group. These outgoing CIDs are dynamically allocated. The incoming connectionless CID however is fixed at 0x002. Although multiple outgoing CIDs may be created to form multiple logical groups. Only one incoming connectionless CID is provided on each L2CAP entity. All incoming connectionless data arrives via this endpoint. These channels do not require connection of configuration information such as upper-level protocol is passed as part of the data packet.
Channels State Machine:
An L2CAP connection “oriented channel endpoint may be in one of several possible states, with data transfer only possible in the OPEN state. Initially, an endpoint is CLOSED, indicating that no channels are associated with the CID. This is the only state in which a base band is not required, and it is the state an endpoint will default to if the page link is disconnected.
Connection:
In order to open a channel, the channel endpoint must be connected and configured. A connection occurs when either the local L2CAP entity requests connection to a remote device or an indication has been received indicating that a remote L2CAP entity is requesting connection to a local CID. In the first case, the request has been passed on to the remote device, and the local entity enters the W4_L2CAP_Connect_RSP state to await a response. In the latter case, the indication is recognized as a connection request, the request has been passed on to the upper layer and the local entity enters the W4_L2CA_Connect_RSP state to await a response. In either case, when the expected response is received, the local device enters the CONFIG state.
Disconnection:
TO close a channel, one L2CAP entity must send a disconnection request to the other. If an entity receives a disconnect request from the upper-level protocol. It passes the request onto the remote device, and the local entity enters the W4+L2CAP_DISCONECT_RSP state to await a response. If the local entity receives an indication that the remote device is requesting disconnection, it sends a disconnection request to the upper layer and then enters the W4_L2CAP_DISCONNECT_RSP state to await a response. In either case, when the expected response is received, the local device enters the CLOSED state.
Packets:
Data is transmitted across channels using packets. A connection-oriented channel uses packets with a 32-bit header followed by a payload of up to 56,535 bytes. The header includes a 16-bit length of payload to use for integrity check and the 16-bit destination CID. The payload contains information received from or being sent to the upper-level protocol. Connectionless channel packets also include a header but always use 0x0002 for the remote CID. In addition, the header is followed by a 16-bit (minimum) protocol/service multiplexer (PSM), which is used to indicate from which upper-level protocol the packet originated. This allows for packet reassembly on the remote device. The PSM field is not required for connection-oriented channels since they are bound to a specific protocol during connection.
Service Discovery Protocol:
The Service Discovery Protocol (SDP) provides a means to determine which Bluetooth services are available on a particular device. A blue tooth device may act as an SDP client querying services, an SDP server providing services, or both. A single Bluetooth device will have no more than one SDP server, but may act as a client to more than one SDP server, but may act as a client to more than one remote device. SDP provides access only to information about services; utilization of those services must be provided via another Bluetooth or third-party protocol. In addition, SDP provides no notification mechanism to indicate that an SDP server, or any specific service, has become available or unavailable as may occur when the service available on a device change, or when a device comes in or out of RF proximity. This would be a common occurrence in a network supporting mobile devices. The client may, of cores poll a server to detect unavailability, but other means are required to detect a server or service that has recently become available.
Service Records:
In SDP a service may provide information per form an action or control a resource. SDP servers maintain service records to catalog all available services provided by the device. A single service record with a dynamically allocated service record handle that is unique within the server represents each service. A special service record with a service record handle of 0x00000000 is provided to describe the SDP server itself and it supported protocols. Service attributes within a service record describe and define the supported service including the service type a service ID. The protocols supported the service name a service description and so on. These attributes are composed of a 16-bit ID and a variable length value. Attribute values in turn include a header field, with a data type and data size, and a data field. A range of data types are supported: null unsigned imager, signed twos-complement integer, universally unique Identifier (UUID), text string, Boolean. Data element sequence (set) data ciement alternative (select one), and URL. The interpretation of this data is dependent on the attribute ID and the service class to which the service belongs.
Discovering Service:
The purpose of SDP is to discover, not access services. Two process are supported: searching and browsing. Searching is based on UUIDs. A service record is returned by a search only if all of the UUIDs in the service search pattern are found within service record attribute values. It does not matter in which attribute a UUID is found, or whether the UUID is only one element in a list, as long as all the search pattern UUIDs are contained somewhere among the attribute values for the service.
Protocol:
SDP is a packet-based protocol utilizing request-response architecture. The SDP packet is referred to as a protocol data unit (PUD). Which includes a header followed by a variable number of parameters. The length of the parameter field is specified in the header, as is the type (PDU ID). Which may indicate a request or response for searches or attribute queries. The header also includes a transaction ID that is used to match a request with a corresponding response. If for some reason the server cannot handle the request it may send a response of type Error Response (PDU ID 0x0).
It is possible that the response may be too large to fit into a single PDU. To accommodate this, a continuation state parameter is supported by most PDUs. In a response, this parameter indicates the number of bytes that are outstanding. The client may then resend the original request, with a new transaction ID, but with the continuation state parameter set. This alerts the server to send the continuation of the response. At what point a response is split is determined by the server.
Three categories of transactions (PDU IDs) are supported: service search transactions service attribute transactions and service search attribute transactions. Service search transitions are used to request a list of service record handles for service records that have attributes containing all of the UUIDs in a service search pattern. There is no mechanism to request all the service records, although browsing is supported as already described. Service attribute transactions are used to request specific attribute values from a service record. Service search attribute transactions combine the service search and service attribute transactions. Which allows getting specific attribute values for all service records that match a service search pattern.
Frame Formats:
The Bluetooth core protocols consist of base-band LMP, L2CAP and SDP. The base band and page link control layer enables the physical RF page link between Bluetooth units forming a piconet. As the Bluetooth RF system is a frequency hopping spread-spectrum system in which packets are transmitted in defined tome slots on defined frequencies, this layer uses inquiry and paging procedures to synchronize the transmission hoping frequency and clock of different Bluetooth device.
The page link manager protocol is responsible for page link setup between Bluetooth devices. This includes security aspects like authentication and encryption by generating, exchanging, and checking page link and encryption keys, and the control and negotiation of base band packet sizes.
L2CAP provides connection-oriented and connectionless data services to the upper-layer protocols with protocol multiplexing capability, segmentation and reassembly, and group abstractions. Discovery services are crucial to the Bluetooth framework. These services provide the basis for all the usage models.
Bluetooth Today and Tomorrow
With the bulk of the work developing the Bluetooth specification complete, the Bluetooth SIG in now working on improvements and analyzing feedback from the industry. In addition to their work investigating improvements in sped security, noise immunity, and so on the SIG continues to develop Bluetooth profiles.
Together with other industry initiatives, such as WAP and Symian, Bluetooth will have tremendous effects on everybody life. Bluetooth is one of the key technologies that can make the mobile information society possible blurring the boundaries between home, office and outside world.
Conclusion:
In the future Bluetooth is likely to be standard in tens of millions of mobile phones, PCs laptops and a whole range of other electronic devices. As a result, the market is going to demand new innovative applications. Value-added services, end “ to “ end solutions, and much more. The possibilities opened up really are limitless and because the radio frequency used is globally available, Bluetooth can offer fast and secure access to wireless connectivity all over the world. With potential like that it is no wonder that Bluetooth is set to become the fastest adopted technology in history.
Bibliography:
1) J.C. Haartsen et al., The Bluetooth Radio System IEEE press. Commun, feb.2000, pp. 28-36
2) M Albrecht et al., IP Services Over Bluetooth: Leading the Way to a New Mobility, IEEE Local Comp. Net., 1999, pp. 22 “ 11.
3) O. Miklos et al., Performance Aspects of Bluetooth Scatter net Formation 1st Mobihoc, Aug. 2000 pp. 147 “ 48.
4) P. Bhanwat, L. Tassiulas, and R. LaMaire, Distributed Topology Construction of Bluetooth Personal Area Network IEEE INFOCOM 2001, Tel Aviv, Israle, Mar. 2000
