WELCOME TO THE SEMINAR OF DATA COMMUNICATION

JASPREET KAUR MCA VII SEM

53

TOPIC:BLUETOOTH
2

INTRODUCTION
STARTED A PROJECT BY ERICSSON COMPANY & NAMED AFTER HARALD BLAATAND WHICH TRANSLATES TO BLUETOOTH WIRELESS LAN CONNECT DEVICES Telephones Notebooks Computers Cameras LAN IS AN ADHOC NETWORK

APPLICATIONS
Peripherals can communicate with computer
Monitoring devices can communicate with sensor devices

Home security use this to connect different sensors to main security controllers
Conference attendees can synchronize their palmtop computers at conference
4

ARCHITECTURE
BLUETOOTH DEFINES TWO TYPES OF NETWORK PICONET SCATTERNET

PICONET
Can have EIGHT stations One MASTER & rest SLAVES PICONET can have only one MASTER

PICONET can have 7 max. of slaves & 8th one in parked state

PICONET
MASTER

SLAVE

SLAVE

SLAVE

SLAVE
7

PICONET
A Blue tooth enabled device, by virtue of the complexity of the communication protocols, needs to operate either as a slave or as a master if it is to communicate with other such devices. This enables the slave to acquire time and frequency synchronization from the master device. Multiple Blue tooth devices may intercommunicate within a given geographic location called 'PICONET'

The resource allocation is determined by the master, but may dynamically reflect the data transfer requirements requested by the individual devices. In a PICONET communication links only exist between a slave and the master - no direct links exist between slaves. The specification limits the number of slaves in a piconet to SEVEN.

SCATTERNET

PICONET CAN BE COMBINED TO FORM CALLED SCATTER NET Slave in one station can become master in other Station can be member of two piconets
10

SCATTERNET
MASTER

SLAVE

SLAVE SLAVE SLAVE SLAVE SLAVE/ MASTER

11

SCATTERNET
The packets carried on the channels are preceded by different channel access codes as determined by the master device addresses. As more piconets are added, the probability of collisions increases; a graceful degradation of performance results as is common in frequency-hopping spread spectrum systems. A Blue tooth unit can act as a slave in several piconets, but only as a master in a single piconet. A group of piconets in which connections consists between different piconets is called a SCATTERNET. 12

BLUE TOOTH PROFILES

13

THE BASE PROFILE

At the base of the profile hierarchy is the generic access profile (GAP), which defines a consistent means to establish a base band link between Blue tooth devices. In addition to this, the GAP defines: Which features must be implemented in all Blue tooth devices Generic procedures for discovering and linking to devices Basic user-interface terminology All other profiles are based on the GAP. This allows each profile to take advantage of the features the GAP provides and ensures a high degree of interoperability between applications and devices.
14

REMAINING PROFILES
The service discovery application profile describes how an application should use the SDP to discover services on a remote device. As required by the GAP, any Blue tooth device should be able to connect to any other Blue tooth device & it requires that any application be able to find out what services are available on any Blue tooth device it connects to. The human interface device (HID) profile describes how to communicate with a HID class device using a Blue tooth link. It describes how to use the USB HID protocol to discover a HID class devices feature set and how a Blue tooth device can support HID services using the L2CAP layer.
15

The serial port profile defines RS-232 serial-cable emulation for Blue tooth devices. As such, the profile allows legacy applications to use Blue tooth as if it were a serial-port link, without requiring any modification. The dial-up networking (DUN) profile is built on the serial port profile and describes how a data-terminal device, such as a laptop computer, can use a gateway device, such as a mobile phone or a modem, to access a telephone-based network. Thus, the modem driver on the data-terminal device is unaware that it is communicating over Blue tooth. The application on the dataterminal device is similarly unaware that it is not connected to the gateway device by a cable.

16

The headset profile describes how a Blue tooth-enabled headset should communicate with a computer or other Blue tooth device (such as a mobile phone). When connected and configured, the headset can act as the remote devices audio input and output interface. The hardcopy cable replacement profile describes how to send rendered data over a Blue tooth link to a device, such as a printer. Although other profiles can be used for printing, the HCRP is specially designed to support hardcopy applications. The object push profile defines the roles of push server and push client. These roles are analogous to and must interoperate with the server and client device roles the generic object exchange profile defines. The object push profile focuses on a narrow range of object formats for maximum interoperability. If an application needs to exchange data in other formats, it should use another 17 profile, such as the file transfer profile.

The generic object exchange profile provides a generic blueprint for other profiles using the OBEX protocol and defines the client and server roles for devices. The profile does not describe how applications should define the objects to exchange or exactly how the applications should implement the exchange. These details are left to the profiles that depend on the generic object exchange profile, namely the object push, file transfer, and synchronization profiles

18

The synchronization profile is another dependent of the generic object exchange profile. It describes how applications can perform data synchronization, such as between a personal data assistant (PDA) and a computer. The synchronization profile focuses on the exchange of personal information management (PIM) data, such as a to-do list, between Blue tooth-enabled devices. A typical usage of this profile would be an application that synchronizes your computers and your PDAs versions of your PIM data. The profile also describes how an application can support the automatic synchronization of datain other words, synchronization that occurs when devices discover each other, rather than at a users command.

19

The file transfer profile is also dependent on the generic object exchange profile. It provides guidelines for applications that need to exchange objects such as files and folders, instead of the more limited objects supported by the object push profile. The file transfer profile also defines client and server device roles and describes the range of their responsibilities in various scenarios.

20

PROTOCOL STACK

21

THE BLUE TOOTH PROTOCOL STACK The heart of the Blue tooth specification is the Blue tooth protocol stack. By providing well-defined layers of functionality, the Blue tooth specification ensures interoperability of Blue tooth devices and encourages adoption of Blue tooth technology

22

Lower Layers
At the base of the Bluetooth protocol stack is the radio layer. The radio module in a Bluetooth device is responsible for the modulation and demodulation of data into RF signals for transmission in the air. The radio layer describes the physical characteristics a Bluetooth devices receiver-transmitter component must have. These include modulation characteristics, radio frequency tolerance, and sensitivity level. Above the radio layer is the base band and link controller layer. The best way to think about it is that the base band portion of the layer is responsible for properly formatting data for transmission to and from the radio layer & it handles the synchronization of links. The link controller portion of this layer is responsible for carrying out the link managers commands
23

The link manager itself translates the host controller interface (HCI) commands it receives into baseband-level operations. It is responsible establishing and configuring links and managing power-change reque among other tasks. The Bluetooth specification defines two types of links between Bluetoo devices: Synchronous, Connection-Oriented (SCO) Asynchronous, Connectionless (ACL) Each link type is associated with a specific packet type. A SCO link provides reserved channel bandwidth for communication between a master and a slave, and supports regular, periodic exchange of data w no retransmission of SCO packets. An ACL link exists between a master and a slave the moment a connection is established. The data packets Bluetooth uses for ACL lin all have 142 bits of encoding information in addition to a payload that can be as large as 2712 bits. It also helps to maintain a robust communication link in an environment filled with other devices and 24 common noise

The HCI (host controller interface) layer acts as a boundary between the lower layers of the Bluetooth protocol stack and the upper layers. For example, a Bluetooth system on a computer might use a Bluetooth modules processor to implement the lower layers of the stack (radio, baseband, link controller, and link manager). It might then use its own processor to implement the upper layers (L2CAP, RFCOMM, OBEX, and selected profiles). In this scheme, the lower portion is known as the Bluetooth module and the upper portion as the Bluetooth host. Because the Bluetooth HCI is well defined, you can write drivers that handle different Bluetooth modules from different manufacturers. Apple provides an HCI controller object that supports a USB implementation of the HCI layer.

25

The HCI is functionally broken up into 3 separate parts:

26

HCI Firmware (location: Host Controller) HCI Firmware , is located on the Host Controller , (e.g. the actual Bluetooth hardware device). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing baseband commands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device HCI Driver (location: Host) HCI Driver , which is located on the Host (e.g. software entity). The Host will receive asynchronous notifications of HCI events, HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit. Host Controller Transport Layer (location: Intermediate Layers) The HCI Driver and Firmware communicate via the Host Controller Transport Layer , i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth : USB , UART and RS232. The Host should receive 27 asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used.

UPPER LAYERS
Above the HCI layer are the upper layers of the protocol stack. The first of these is the L2CAP (logical link control and adaptation protocol) layer. The L2CAP is primarily responsible for: Establishing connections across existing ACL links or requesting an ACL link if one does not already exist Multiplexing between different higher layer protocols, such as RFCOMM and SDP, to allow many different applications to use a single ACL link Repackaging the data packets it receives from the higher layers into the form expected by the lower layers The L2CAP employs the concept of channels to keep track of where data packets come from and where they should go. You can think of a channel as a logical representation of the data flow between the L2CAP layers in remote devices. Because it plays such a central role in the communication between the upper and lower layers of the Bluetooth protocol stack, the L2CAP layer is a required part of every Bluetooth system.
28

DUTIES OF L2CAP
Protocol Multiplexing

L2CAP must support protocol multiplexing because the Baseband Protocol does not support any type field identifying the higher layer protocol being multiplexed above it. L2CAP must be able to distinguish between upper layer protocols such as the Service Discovery Protocol , RFCOMM , and Telephony Control .

Segmentation & Reassembly

Large L2CAP packets must be segmented into multiple smaller Baseband packets prior to their transmission over the air. Similarly, multiple received Baseband packets may be reassembled into a single larger L2CAP packet following a simple integrity check. The Segmentation and Reassembly (SAR) functionality is absolutely necessary to support protocols using packets larger than those supported by the Baseband.
29

Quality of Service The L2CAP connection establishment process allows the exchange of information regarding the quality of service (QoS) expected between two Bluetooth units. Each L2CAP implementation must monitor the resources used by the protocol and ensure that QoS contracts are honored. Groups Many protocols include the concept of a group of addresses. For example 2 or 3 slaves devices can be part of multicast group to receive data from master

30

The SDP (service discovery protocol) defines actions for both servers and clients of Bluetooth services. The specification defines a service as any feature that is usable by another (remote) Bluetooth device. A single Bluetooth device can be both a server and a client of services. An example of this is the Macintosh computer itself. An SDP client communicates with an SDP server using a reserved channel on an L2CAP link to find out what services are available. When the client finds the desired service, it requests a separate connection to use the service. The reserved channel is dedicated to SDP communication so that a device always knows how to connect to the SDP service on any other device. An SDP server maintains its own SDP database, which is a set of service records that describe the services the server. The RFCOMM protocol emulates the serial cable line settings and status of an RS-232 serial port. RFCOMM connects to the lower layers of the Bluetooth protocol stack through the L2CAP layer.

31

OBEX (object exchange) is a transfer protocol that defines data objects and a communication protocol two devices can use to easily exchange those objects. Bluetooth adopted OBEX from the IrDA IrOBEX specification because the lower layers of the IrOBEX protocol are very similar to the lower layers of the Bluetooth protocol stack. A Bluetooth device wanting to set up an OBEX communication session with another device is considered to be the client device. The client first sends SDP requests to make sure the other device can act as a server of OBEX services. If the server device can provide OBEX services, it responds with its OBEX service record. This record contains the RFCOMM channel number the client should use to establish an RFCOMM channel. Further communication between the two devices is conveyed in packets, which contain requests and responses, and data. The format of the packet is defined by the OBEX session protocol.

32

BLUETOOTH FRAME STRUCTURE

Each packet consists of 3 entities, the access code (68/72 bits), the header (54 bits) , and the payload (0-2745 bits).
*

33

Access Code: Access code are used for timing synchronization,

offset compensation, paging and inquiry. There are three different types of Access code: Channel Access Code (CAC), Device Access Code (DAC) and Inquiry Access Code (IAC). The channel access code identifies a unique piconet while the DAC is used for paging and its responses. IAC is used for inquiry purpose. Header:The header contains information for packet acknowledgement, packet numbering for out-of-order packet reordering, flow control, slave address and error check for header. Payload: The packet payload can contain either voice field, data field or both. It it has a data field, the payload will also contain a payload header.

34

Thanks!!!

35