Wireless Personal area networksWPANs

ByEngr. Sherjeel

Farooqui

Overview of wireless networks

PAN802.15.

x10m

LAN802.11100m

MAN802.162-6km

WAN2G, 3G2km/linknationalareas

IEEE 802.15 - General Wireless Personal Area Networks (WPANs)

Short Range Low Power Low Cost Small Networks

Communication within a persons operating space

802.15 division

IEEE 802.15 is the 15th working group of the IEEE 802

which specializes in Wireless PAN (Personal Area Network) standards.

It includes four main task groups (numbered from 1 to 4).

802.15 Task Groups

Task group 1 (WPAN/Bluetooth)IEEE 802.15.1-2002 has derived a Wireless Personal Area Network standard based on the Bluetooth v1.1 specifications. It includes a medium access control and physical layer specification. An updated version, IEEE 802.15.1-2005, has been published.

Task group 2 (Coexistence)IEEE 802.15.2-2003 addresses the issue of coexistence of wireless personal area networks (WPAN) with other Wireless Devices operating in Unlicensed Frequency Bands such as wireless local area networks (WLAN).

802.15 Task Groups

Task group 3 (High Rate WPAN)IEEE 802.15.3-2003 is a MAC and PHY standard for high-rate (11 to 55 Mb/s) WPANs , for applications which involve imaging and multimedia.

Task group 4 (Low Rate WPAN)IEEE 802.15.4-2003 (Low Rate WPAN) deals with low data rate but very long battery life (months or even years) and very low complexity. The first edition of the 802.15.4 standard was released in May 2003. In March 2004, after forming Task Group 4b, task group 4 put itself in hibernation.

The ZigBee set of high level communication protocols is based upon the specification produced by the IEEE 802.15.4 task group

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

www.bluethooth.com

Bluetooth’s Objectives

Global usage.

Voice and data handling.

The ability to establish ad-hoc connections.

The ability to withstand interference from other sources in open band.

Very small size, in order to accommodate integration into variety of devices

Negligible power consumption in comparison to other devices for similar use.

An open interface standard.

Competitively low cost of all units, as compared to their non-Bluetooth Correspondents.

APPLICATIONS OF BLUETOOTH

Phones and pagers Modems LAN access devices Headsets Notebook computers Desktop and handheld computers Printers Fax machines Keyboards Joysticks

Bluetooth Application Areas

Data and voice access points Real-time voice and data transmissions

Cable replacement Eliminates need for numerous cable attachments for

connection

Ad hoc networking Device with Bluetooth radio can establish connection

with another when in range

Features of Bluetooth Technology

Bluetooth is based upon small, high performance integrated radio transceivers, each of which is allocated a unique 48-bit address derived from the IEEE 802 standards.

It operates in the unrestricted 2.4 GHz ISM "free band", which is available globally, although slight variation of location and width of band apply.

Bluetooth uses the unlicensed ISM (Industrial, Scientific and Medical) band, 2400 - 2483.5 MHz, thereby maximizing communication compatibility worldwide

The range is set at 10 meters to optimize for target market of mobile and business user. The range can, however, be increased to 100 meters.

Gross data rate is 1Mbit/s, with second generation providing increase to 2Mbit/s, and further to 3Mbits/s

Personal Ad-hoc Personal Ad-hoc NetworksNetworks

Cable Cable ReplacementReplacement

Landline

Data/Voice Data/Voice Access PointsAccess Points

What does Bluetooth do for you?

Features of Bluetooth Technology

Bluetooth uses a packet switching protocol, based on a frequency hoping scheme with 1600 hops/sec to enable high performance in noisy radio environments.

The entire available frequency spectrum is used with 79 hops of 1 MHz bandwidth, analogous to the IEEE 802.11 standard.

It has low power consumption, drawing only 0.3 mA in standby mode. This enables maximum performance longevity for battery-powered devices.

During data transfer the maximum current drain is 30 mA. However, during pauses or at lower data rates the drain would be lower.

Frequency hopping The total bandwidth is divided into 79 physical channels. (almost in every

country)

Each channel has the bandwidth of 1 MHz.

FH occurs by jumping from one channel to another in pseudorandom sequence.

The hop rate is 1600 hops/sec

Each physical channel is occupied for 0.625ms which is referred as a slot.

Bluetooth uses FH-TDD-TDMA.

Link data rate -  a maximum link baseband data rate of 723.2 kb/s is supported, with options for  1/3 bit repetition and 2/3 Hamming FEC (Forward Error Correction).

Speech coding - CVSD - 64kb/s Continuously Variable Slope Delta Modulation.  CVSD supports acceptable speech quality even with 1-3% bit error rate, BER. 

• We can only predict the hopping sequence if we know two pieces of information.

•The first is a portion (the 28 lowest bits) of the piconet master device's numeric address (the "MAC address" or more properly "BD_ADDR"), and the second is the master's clock, a 28 bit integer value that increments 3200 times per second.

•If we know both the address and the clock at a particular time, then we can correctly predict the hopping sequence forever. We just have to use the hopping algorithm dictated by the Bluetooth specification.

Hopping Sequence

Hopping Sequence In total, six types of hopping sequence are defined − five for the

basic hop system and one for an adapted set of hop locations used by adaptive frequency hopping (AFH). These sequences are:

An inquiry hopping sequence with 32 wake-up frequencies distributed equally over the 79 MHz, with a period length of 32;

An inquiry response hopping sequence covering 32 response frequencies that are in a one-to-one correspondence to the current inquiry hopping sequence.

A page hopping sequence with 32 wake-up frequencies distributed equally over the 79 MHz, with a period length of 32;

Hopping Sequence A page response hopping sequence covering 32 response frequencies

that are in a one-to-one correspondence to the current page hopping sequence. The master and slave use different rules to obtain the same sequence;

A basic channel hopping sequence which has a very long period length, which does not show repetitive patterns over a short time interval, and which distributes the hop frequencies equally over the 79 MHz during a short time interval.

An adapted channel hopping sequence derived from the basic channel hopping sequence which uses the same channel mechanism and may use fewer than 79 frequencies. The adapted channel hopping sequence is only used in place of the basic channel hopping sequence. All other hopping sequences are not affected by hop sequence adaptation.

Technical Features 2.4 GHz ISM Open Band

Globally free available frequency 79 MHz of spectrum = 79 channels Frequency Hopping & Time Division Duplex (1600 hops/second)

10-100 Meter Range Class I – 100 meter (300 feet may be 100mW) Class II – 20 meter (60 feet with min of 0.25mW(-6dBm) to

2.4mW(4dBm)) Class III – 10 meter (30 feet 1mW)

1 Mbps Gross Rate

Simultaneous Voice/Data Capable

Where Does Bluetooth stand

Frequency Hopping

Bluetooth Topologies

There are 3 types of connections in Bluetooth:

Single-slave

Multi-slave (up to 7 ”slaves” on one master)

Scatternet

Piconet A piconet is a collection of devices

connected via Bluetooth technology in an ad-hoc fashion.

A piconet starts with two connected devices, such as a portable PC and a mobile phone.

The limit is set at 7 units in a piconet (that’s why the required address-space is limited to 3 bits).

All Bluetooth devices are peer units and

have identical implementations.

However, when establishing a piconet, one unit will act as a master for synchronization purposes, and the other unit/units will be slave/slaves for the duration of the piconet connection.

Scatternet A scatternet is a combination of

two or more independent non-synchronized piconets that communicate with each other.

A slave as well as a master unit in one piconet can establish this connection by becoming a slave in the other piconet.

It will then relay communications between the piconets, if the need arises.

Addressing Bluetooth device address (BD_ADDR)

48 bit IEEE MAC address

Active Member address (AM_ADDR) 3 bits active slave address all zero broadcast address

Parked Member address (PM_ADDR) 8 bit parked slave address

Forming A Piconet

Initially, devices Known only about themselves

No Synchronization Every one Monitors in standby mode All devices have the capability of serving as master or

slave

Forming a Piconet Unit establishing the Piconet automatically becomes

the master.

It sends an inquiry to discover what other devices are out there.

Addressing

Active devices are assigned a 3-bit active member address(AMA)

Parked devices are assigned an 8-bit parked member address. (PMA)

Standby devices do not need an address.

States

Types of Access Codes

Channel access code (CAC) identifies a piconet

Device access code (DAC) used for paging and subsequent responses

Inquiry access code (IAC) used for inquiry purposes

Connection establishment and connection states

Inquiry

Inquiry Procedure Potential master identifies devices in range that

wish to participate

Transmits ID packet with inquiry access code (IAC) Occurs in Inquiry state

Device receives inquiry

Enter Inquiry Response state Returns FHS packet with address and timing

information Moves to page scan state

Page Procedure Master uses devices address to calculate a page frequency-hopping sequence

Master pages with ID packet and device access code (DAC) of specific slave

Slave responds with DAC ID packet

Master responds with its FHS packet

Slave confirms receipt with DAC ID

Slaves moves to Connection state

Connecting To Pico Net Device in standby listens

periodically

If device wants to establish a Piconet, it sends an inquiry, broadcast over all wake-up carriers.

It will become master of the Piconet. If inquiry was successful, devices

enter in the page mode.

Devices in standby may respond to the inquiry with its device address.

It will become slave to that master

Page and Connect States After receiving a response

from each device, the master can connect to each device individually

An AMA is assigned

Slave synchronize to the hopping sequence established by the master.

In Active states, master and slave listen, transmit and receive.

Low Power State Sniff state

Slaves listen to Piconet at a reduce rate.

Master designates certain slot to transmit to slaves in sniff state.

Hold state Slave stops ACL Transmission,

but exchange SCO Packets only.

Park State Slave releases AMA address and

receive PM address. Still FH synchronized and wakes

up periodically to listen to becon.

Scatternet Piconet with overlapping coverage use different hopping sequences

Collisions may occurs wile multiple Piconet uses same carrier frequency at the same time.

Devices can participate in multiple Piconet simultaneously, creating a scatternet

A devices can only be the master of one Piconet at a time.

A device ma serve as Master in One Piconet and Slave in other Piconet.

A device may serve as slave in multiple piconets.

Scatternet

Piconet channel

m

s1

s2

625 sec

f1 f2 f3 f4

1600 hops/sec

f5 f6

FH/TDD

Multi slot packets (ACL)

m

s1

s2

625 sec

f1 f4 f5 f6

Data rate depends on type of packetPacket can be 1,3,5 slots long. For complete transmission same

frequency is used, after transmission the frequency in hope sequence is selected

Multi slot packets (ACL)

m

s1

s2

625 sec

f1 f6

Data rate depends on type of packetPacket can be 1,3,5 slots long. For complete transmission same

frequency is used, after transmission the frequency in hope sequence is selected

Physical Link Types Synchronous Connection Oriented (SCO) Link

Allocate fixed bandwidth between a point to point connection involving master and a single slave.

Master maintains the two consecutive slot for SCO link one for each side.

No ARQ, No CRC

Master can support upto three SCO link and slave can support up to two SCO link.

FEC (optional)

64 Kbps

Physical Link Types

Asynchronous Connection-less (ACL) Link Only single ACL link can exsist.

It is the slot which is not used by the SCO Link

Polling access method

ARQ, CRC

FEC (optional)

Symmetric data rate 108 - 433 Kbps

Asymmetric data rate up to 723 Kbps

Description of Payload Type

Mixed Link Examplem

s1

s2

SCO SCO SCOACL ACL ACLACL ACL ACL

Packet Format

Access code

Header Payload

72 bits 54 bits 0 - 2745 bits

Synchronizationidentification

Filtering

AddressPacket TypeFlow controlARQSEQNHEC

Error correction1/3 rate FEC2/3 rate FEC

ARQ scheme for the data

Smaller than an ATM cell !

Bluetooth Packet Fields

Access code – used for timing synchronization, offset compensation, paging, and inquiry

Header – used to identify packet type and carry protocol control information

Payload – contains user voice or data and payload header, if present

Composition Of Access Code

Preamble

Sync Word Trailer4 bits 64 bits 4 bits

•It consist of pattern 0101 if the least significant bit (Left most bit) of the SYNC word is 0.

•It consist of pattern 1010 if the least significant bit (Left most bit) of the SYNC word is 1.

•It consist of pattern 0101 if the most significant bit (Right most bit) of the SYNC word is 1.

•It consist of pattern 1010 if the most significant bit (Right most bit) of the SYNC word is 0.

•24 bits of Least Significant Bit of address is known as LAP (Lower address Part) and are used for forming a sync word.

• For CAC LAP of master is used.•For DAC LAP of slave is used.•There are two types of IAC

•General (GIAC) •Dedicated (DIAC)

24 bits

Preamble

Sync Word Trailer4 bits 64 bits 4 bits

Composition Of Access Code

Composition Of Access Code

Composition Of Access Code

Determine 24-bit Lower Address Part (LAP) of Bluetooth device address (48 bit IEEE MAC address) a device address or reserved inquiry address is used

Append 6-bit Barker sequence to LAP to improve auto-correlation properties

XOR new sequence with bits 34 to 63 of full length, 64-bit Pseudorandom Noise (PN) sequence Encode resulting 30-bit sequence with (64,30) BCH (Bose-Chaudhuri-Hocquenghem) block code to obtain 34 parity bits

34-bit parity word XOR’d with the remaining bits, 0 to 33 of PN sequence to remove cyclic properties of block code

Packet Format

Access code

Header Payload

72 bits 54 bits 0 - 2745 bits

Synchronizationidentification

Filtering

AddressPacket TypeFlow controlARQSEQNHEC

Error correction1/3 rate FEC2/3 rate FEC

ARQ scheme for the data

Smaller than an ATM cell !

Header

Header part of the packet is used by the Link Control (LC) logical channel. It has the following Fields:

AM_ADDR:[3 bits] temporary address assigned to active members of the piconet, used on all packets in both direction sent between the master and the addressed slave. An all-zero AM_ADDR is used to broadcast to all slaves.

TYPE:[4 bits] type of packet. There are 12 types of packets for each SCO and ACL physical links, and four types of common control packets for both.

FLOW:[1 bits] for flow control.

ARQN:[1 bits] for ACK.

SEQN:[1 bits] contains sequence number for packet ordering.

HEC:[8 bits] header error check for header integrity.

FAST ARQ

ARQN provides a 1 bit acknowledgement mechanism for ACL traffic protected by CRC. If reception was successful an ACK i.e AKQN=1 is returned ; otherwise a NAK (ARQN=0) is returned. When no ACK arrives for a given time packet is transmitted again.

SEQN of one bit provide intelligent numbering scheme in which transmitted packages are labeled 1 and 0 alternately. If a retransmission occurs due to failing ACK, same bit packet arrives twice meaning retransmission of previous packet.

Achievable Data Rates on the ACL Link

Type Symmetric (Kbps)

Asymmetric (Kbps)

DM1 108.8 108.8 108.8

DH1 172.8 172.8 172.8

DM3 256.0 384.0 54.4

DH3 384.0 576.0 86.4

DM5 286.7 477.8 36.3

DH5 432.6 721.0 57.6

• DMx = x-slot FEC-encoded• DHx = x-slot unprotected

Achievable Data rates unprotected

Paylo

ad

Typ

e

Packet Types 13 different packet types are defined for the

baseband layer of the Bluetooth system. All higher layers use these packets to compose higher level PDU's.

The packets are ID, NULL, POLL, FHS , DM1 ; these packets are defined for both SCO and ACL links. 

DH1, AUX1, DM3, DH3, DM5, DH5 are defined for ACL links only. 

HV1, HV2, HV3 , DV are defined for SCO links only   

Packet Types (SCO & ACL) ID

A 68-bit packet used in paging , inquiry and response routines. It is essentially the device access code (DAC) or inquiry access code (IAC)

NULL packet A 126-bit packet consisting of the CAC and packet header only. It is used to

return link information to the source. The NULL packet does not have to be acknowledged

POLL Packets Similar to the NULL packet, except it requires a confirmation from

the destination. Upon reception of a POLL packet the slave must respond with a packet.

Packet Types (SCO & ACL) FHS

Frequency Hopping Synchronization. This a special control packet revealing, among other things, the BD_ADDR and the clock of the source device. It contains 144 info bits and a 16-bit CRC code. The payload is coded with a rate 2/3 FEC which brings the total payload length to 240 bits. The FHS packet covers a single time slot.

DM1 Data - Medium Rate. An ACL link data packet type for medium rate data.

DM1 packets carry information data only, contining a 16-bit CRC code and up to 18 info bytes. They are encoded using 2/3 FEC and the packet can cover up to a single time slot. DM3 packets are the same except they can cover up to 3 time slots, and can carry up to 123 info bytes. DM5 packets are the same again except they  can cover up to 5 time slots and can hold up to 226 info bytes.

Packet Types (ACL)

AUX1 An ACL link packet type for data. An AUX1 packet resembles

a DH1 packet except it has no CRC code. As a result it can can carry up to 30 info bytes.

DM3 DM3 packets are the same as DM1 except they can cover up

to 3 time slots, and can carry up to 123 info bytes.

DM5 DM5 packets are the same again except they  can cover up to

5 time slots and can hold up to 226 info bytes.

Packet Types (ACL) DH1

Data-High Rate. An ACL link data packet type for high rate data. DH1 packets are similar to  DM1 packets, except the info in the payload is not FECencoded. This means the DH1 packet can carry up to 28 info bytes and covers a single time slot.

DH3 The DH3 is the same except it can cover up to 3 time slots and

contain up to 185 info bytes. DH5

The DH5 packet is the same again except it can cover up to 5 time slots and contains up to 341 info bytes.

Packet Types (SCO) DV

Data Voice. A SCO link data packet type for data and voice.It is divided into a voice field of 80 bits and a data field of 150 bits. The voice field is not covered by FEC, but the data field is covered by 2/3 FEC. The voice and data fields are treated completely separate. The voice field is handled like normal SCO data and is never retransmitted; that is, the voice field is always new. The data field is checked for errors and is retransmitted if necessary.

High quality Voice. A SCO link voice packet. HV packets do not have a CRC or payload header HV1 packets carry 10 info bytes, which are protected by

1/3 FEC. HV2 packets carry 20 info bytes, and are protected by 2/3 FEC. HV3 packets carry 30 info bytes, and not protected by FEC.

Bluetooth Architecture

Bluetooth is both a hardware-based radio system and a software stack that specifies the linkages between layers.

This supports flexibility in implementation across different devices and platforms. It also provides robust guidelines for maximum interoperability and compatibility.

Bluetooth protocol stack. The protocol stack is the core of the Bluetooth specification that defines how the technology works

Bluetooth profiles. The profiles define how to use Bluetooth technology to accomplish specific tasks

Protocol Architecture Cable replacement protocol

RFCOMM Telephony control protocol

Telephony control specification – binary (TCS BIN) Adopted protocols

PPP TCP/UDP/IP OBEX WAE/WAP

OSI , IEEE and IEEE 802.15.1

Lower Layers

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 device’s receiver-transmitter component must have. These include modulation characteristics, radio frequency tolerance, and sensitivity level.

Baseband / Link controller layer:The Bluetooth specification doesn’t establish a clear distinction between the responsibilities of the baseband and those of the link controller. The best way to think about it is that the baseband portion of the layer is responsible for properly formatting data for transmission to and from the radio layer. In addition, it handles the synchronization of links. The link controller portion of this layer is responsible for carrying out the link manager’s commands and establishing and maintaining the link stipulated by the link manager.

Link Manager: Responsible for authentication, encryption, plus control and negotiate base band packet size.

Lower Layers HCI (host controller interface) layer :

HCI acts as a boundary between the lower layers of the Bluetooth protocol stack and the upper layers. The Bluetooth specification defines a standard HCI to support Bluetooth systems that are implemented across two separate processors. For example, a Bluetooth system on a computer might use a Bluetooth module‘s 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.

(It’s not required to partition the Bluetooth stack in this way. Bluetooth headsets, for example , combine the module and host portions of the stack on one processor because they need to be small and self-contained. In such devices, the HCI may not be implemented at all unless device testing is required.)

Upper Layers

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.

SDP (service discovery protocol): 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. An example of this is the Macintosh computer itself using the file transfer profile ,the Macintosh computer can browse the files on another device and allow other devices to browse its files.

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 offers. Along with information describing how a client can connect to the service, the service record contains the service’s UUID, or universally unique identifier.

Upper layers

RFCOMM layer: 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. By providing serial-port emulation, RFCOMM supports legacy serial-port applications.

OBEX (object exchange) transfer protocol

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. In addition, the IrOBEX protocol is already widely accepted and therefore a good choice for the Bluetooth SIG, which strives to promote adoption by using existing technologies.

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.

OBEX can be supported over TCP/IP

The Bluetooth Profiles

The Bluetooth specification defines a wide range of profiles, describing many different types of tasks, some of which have not yet been implemented by any device or system. By following the profiles’s procedures, developers can be sure that the applications they create will work with any device that conforms to the Bluetooth specification. For information on other profiles, including those still in development, see the Bluetooth specification.

At a minimum, each profile specification contains information on the following topics:

Dependencies on other profiles. Every profile depends on the base profile, called the generic access profile, and some also depend on intermediate profiles.

Suggested user interface formats. Each profile describes how a user should view the profile so that a consistent user experience is maintained.

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.

The Bluetooth profiles

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 Bluetooth devices.

In addition to this, the GAP defines: Which features must be implemented in all Bluetooth

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. It also makes it easier for developers to define new profiles by leveraging existing definitions.

Bluetooth Profiles Service discovery application profile describes how an application

should use the SDP to discover services on a remote device Human interface device (HID) profile describes how to communicate

with a HID class device using a Bluetooth link. Serial port profile defines RS-232 serial-cable emulation for Bluetooth

devices. As such, the profile allows legacy applications to use Bluetooth as if it were a serial-port link, without requiring any modification. The serial port profile uses the RFCOMM protocol to provide the serial-port emulation.

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.

Headset profile describes how a Bluetooth-enabled headset should communicate with a computer or other Bluetooth device (such as a mobile phone). When connected and configured, the headset can act as the remote device’s audio input and output interface.

Hardcopy cable replacement profile describes how to send rendered data over a Bluetooth 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.

Bluetooth Profiles Generic object exchange profile provides a generic blueprint for other

profiles using the OBEX protocol and defines the client and server roles for devices. As with all OBEX transactions, the generic object exchange profile stipulates that the client initiate all transactions. The profile does not, however, 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.

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. The most common of the acceptable formats is the vCard format. If an application needs to exchange data in other formats, it should use another profile, such as the file transfer profile

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