Welcome to the Seminar of Data Communication

7/29/2019 Welcome to the Seminar of Data Communication

1/35

1

WELCOME TO THESEMINAR OF DATA

COMMUNICATION

JASPREET KAUR

MCA VII SEM

53


2/35

2

TOPIC:-

BLUETOOTH


3/35

3

INTRODUCTION

STARTED A PROJECT BYERICSSON COMPANY &NAMED AFTERHARALD BLAATANDWHICH

TRANSLATES TOBLUETOOTH

WIRELESS LAN CONNECT DEVICES

TelephonesNotebooks

Computers

Cameras

LAN IS AN ADHOC NETWORK


4/35

4

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


5/35

5

ARCHITECTURE

BLUETOOTH DEFINES TWO TYPES

OF NETWORK

PICONET

SCATTERNET


6/35

6

PICONET

Can haveEIGHTstations

OneMASTER& restSLAVES

PICONET can have only one MASTER

PICONET can have 7 max. of slaves& 8th onein parked

state


7/35

7

SLAVE

PICONET

MASTER

SLAVE SLAVE SLAVE SLAVE


8/35

8

PICONET

A Blue tooth enabled device, by virtue of thecomplexity 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'


9/35

9

The resource allocation is determined by the

master, but may dynamically reflect the datatransfer 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.


10/35

10

SCATTERNET

PICONET CAN BECOMBINED TO

FORM CALLED SCATTER NET

Slave in one station can become master

in other

Station can be member of two piconets


11/35

11

MASTER

SLAVE SLAVE SLAVE SLAVE/

MASTER

SLAVE

SLAVE

SCATTERNET


12/35

12

SCATTERNETThe 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 spectrumsystems.

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.


13/35

13

BLUE TOOTH

PROFILES


14/35

14

THE BASE PROFILE

At the base of the profile hierarchy is the generic accessprofile (GAP), which defines a consistent means to establish abase band link between Blue tooth devices. In addition to this,the GAP defines:

Which features must be implemented in all Blue tooth

devicesGeneric procedures for discovering and linking to devices

Basic user-interface terminology

All other profiles are based on the GAP. This allows eachprofile to take advantage of the features the GAP provides andensures a high degree of interoperability between applicationsand devices.


15/35

15

The service discovery application profile describes how anapplication 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 onany 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 HIDclass devices feature set and how a Blue tooth device can

support HID services using the L2CAP layer.

REMAINING PROFILES


16/35

16

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.

Thedial-up networking (DUN) profileis 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 data-

terminal device is similarly unaware that it is not connected to thegateway device by a cable.


17/35

17

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 outputinterface.

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 pushprofile 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

profile, such as the file transfer profile.


18/35

18

The generic object exchange profile provides a generic

blueprint for other profiles using the OBEX protocol anddefines 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


19/35

19

The synchronization profile is another dependent of the

generic object exchange profile. It describes how applicationscan perform data synchronization, such as between a personaldata assistant (PDA) and a computer. The synchronizationprofile focuses on the exchange of personal informationmanagement (PIM) data, such as a to-do list, between Blue

tooth-enabled devices. A typical usage of this profile would bean application that synchronizes your computers and yourPDAs versions of your PIM data. The profile also describeshow an application can support the automatic synchronizationof datain other words, synchronization that occurs when

devices discover each other, rather than at a users command.


20/35

20

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 transferprofile also defines client and server device roles and

describes the range of their responsibilities in various

scenarios.


21/35

21

PROTOCOL STACK
http://www.palowireless.com/infotooth/tutorial/rfcomm.asphttp://www.palowireless.com/infotooth/tutorial/hci.asphttp://www.palowireless.com/infotooth/tutorial/sdp.asphttp://www.palowireless.com/infotooth/tutorial/radio.asphttp://www.palowireless.com/infotooth/tutorial/baseband.asphttp://www.palowireless.com/infotooth/tutorial/lmp.asphttp://www.palowireless.com/infotooth/tutorial/l2cap.asp


22/35

22

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


23/35

23

Lower LayersAt the base of the Bluetooth protocol stack is theradiolayer. The radio module in a Bluetooth device is

responsible for the modulation and demodulation of datainto RF signals for transmission in the air. The radiolayer describes the physical characteristics a Bluetoothdevices receiver-transmitter component must have.These include modulation characteristics, radio

frequency tolerance, and sensitivity level.Above the radio layer is the base band andlinkcontroller layer. The best way to think about it is that thebase band portion of the layer is responsible for properlyformatting data for transmission to and from the radio

layer & it handles the synchronization of links. The linkcontroller portion of this layer is responsible for carryingout the link managers commands


24/35

24

The link manager itself translates the host controller interface (HCI)commands it receives into baseband-level operations. It is responsibleestablishing and configuring links and managing power-change requeamong other tasks.

The Bluetooth specification defines two types of links between Bluetodevices:

Synchronous, Connection-Oriented (SCO)

Asynchronous, Connectionless (ACL)

Each link type is associated with a specific packet type. A SCO linkprovides reserved channel bandwidth for communication between amaster and a slave, and supports regular, periodic exchange of datano retransmission of SCO packets.

An ACL link exists between a master and a slave the moment aconnection is established. The data packets Bluetooth uses for ACL liall have 142 bits of encoding information in addition to a payload thatcan be as large as 2712 bits. It also helps to maintain a robustcommunication link in an environment filled with other devices and

common noise


25/35

25

The HCI (host controller interface) layer acts as a boundarybetween the lower layers of the Bluetooth protocol stack and

the upper layers. For example, a Bluetooth system on acomputer might use a Bluetooth modules processor toimplement the lower layers of the stack (radio, baseband, linkcontroller, and link manager). It might then use its ownprocessor to implement the upper layers (L2CAP, RFCOMM,

OBEX, and selected profiles). In this scheme, the lowerportion is known as the Bluetooth module and the upperportion as the Bluetooth host.

Because the Bluetooth HCI is well defined, you can writedrivers that handle different Bluetooth modules from

different manufacturers. Apple provides an HCI controllerobject that supports a USB implementation of the HCI layer.


26/35

26

The HCI is functionally broken up into 3 separate parts:

rmware oca on: o

s on ro er


27/35

27

rmware oca on: os on ro erHCI Firmware , is located on the Host Controller , (e.g. the actualBluetooth

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 deviceHCI 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 ControllerTransport 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

asynchronous notifications of HCI events independent of which HostController Trans ort La er is used.

UPPER LAYERS


28/35

28

Above the HCI layer are the upper layers of the protocol stack. The firstof 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 anACL link if one does not already exist

Multiplexing between different higher layer protocols, such asRFCOMM and SDP, to allow many different applications to use a singleACL link

Repackaging the data packets it receives from the higher layers intothe form expected by the lower layers

The L2CAP employs the concept of channels to keep track of wheredata packets come from and where they should go. You can think of achannel as a logical representation of the data flow between the L2CAP

layers in remote devices. Because it plays such a central role in thecommunication between the upper and lower layers of the Bluetoothprotocol stack, the L2CAP layer is a required part of every Bluetoothsystem.

UPPER LAYERS


29/35

29

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 packetfollowing 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.

DUTIES OF L2CAP


30/35

30

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


31/35

31

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 usableby 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 reservedchannel 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 anRS-232 serial port. RFCOMM connects to the lower layers of the Bluetooth

protocol stack through the L2CAP layer.


32/35

32

OBEX (object exchange) is a transfer protocol that defines data objectsand a communication protocol two devices can use to easily exchangethose objects. Bluetooth adopted OBEX from the IrDA IrOBEX

specification because the lower layers of the IrOBEX protocol are verysimilar to the lower layers of the Bluetooth protocol stack.

A Bluetooth device wanting to set up an OBEX communication sessionwith 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 itsOBEX service record. This record contains the RFCOMM channelnumber the client should use to establish an RFCOMM channel.

Further communication between the two devices is conveyed inpackets, which contain requests and responses, and data. The format ofthe packet is defined by the OBEX session protocol.


33/35

33

Each packet consists of 3 entities, the access code (68/72 bits), the header (54 bits) ,

and the payload (0-2745 bits).*

BLUETOOTH FRAME

STRUCTURE


34/35

34

Access Code: Access code are used for timing synchronization,

offset compensation, paging and inquiry. There are three differenttypes 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.


35/35

35

Thanks!!!

Welcome to the Seminar of Data Communication

Documents

Transcript of Welcome to the Seminar of Data Communication