16-03-2011, 02:35 PM
presented by:
PRANEETH SURAPANENI
NAVYA PUTUMBAKA
[attachment=10311]
ABSTRACT
The seemingly endless entanglement of data wires connecting today’s electronic devices has become slightly less jumbled with the introduction of Bluetooth technology and the creation of a wireless data link. This article delves into the implementation and architecture of Bluetooth. It also describes the functional overview and applications of Bluetooth. It gives significant advantages of Bluetooth over other data transfer technologies such as IrDA and Home RF. It illustrates how a
connection is made in Bluetooth between two environments. It mainly emphasizes the architecture of Bluetooth. It gives over all Bluetooth packet structure and different communication and data information protocols such as WAP, UDP, IP,TCP ,RFCOMM, L2CAP etc. It also explains Link Security by Data Encryption. Finally it narrates how Bluetooth will bring a new level of connectivity and convenience when operating electronic devices. These details in the article establish the growing need for Bluetooth technology.
INTRODUCTION
Bluetooth is a method for data communication that uses short-range radio links to replace cables between computers and their connected units. Bluetooth is a radio frequency technology utilizing the unlicensed 2.5GHz industrial, scientific and medical (ISM) band. Bluetooth is an open standard for wireless connectivity with supporters mostly from the PC and cell phone industries. Not surprisingly, its primary market is for data and voice transfer between communication devices and PCs. Bluetooth was invented by L.M.Ericson of Sweden in 1994. The standard is named after Harald Blaatand"Bluetooth"2nd,king of Denmark.
WHY BLUETOOTH?
Bluetooth attempts to provide significant advantages over other data transfer technologies such as IrDA and HomeRF. IrDA is already popular in PC to peripherals,but is severely limited by the short connection distance of 1m and the line of sight requirement for communication. Due to its RF nature bluetooth is not subjected to such limitations. In addition to wireless device connections up to 10-100m, devices need not be within line of sight. Also it is designed to be low cost i.e under $10/unit.
Establishing a connection in Bluetooth:
Linking one Bluetoooth device to another to another involves a series of inquiry and paging procedures. The inquiry process entails the following steps:
• The Bluetooth device sends out an inquiry access code packet (inquiry packet) to search and locate these devices.
• The existing Bluetooth devices already within the area (and usually unware of any inquiring devices) will occasionally enter an inquiry scan state of their own to troll for any inquiring devices.
• When a device in the inquiry scan state receives an inquiry packet, it will respond with a frequency hop synchronization (FHS) packet that is sent back to the inquiring device.
Once the inquiry routine is completed, the paging process follows:
• The inquiring Bluetooth device now wants to establish a connection with another Bluetoooth device.
• To successfully locate and page a target Bluetooth device, the paging device estimates the hop frequency and clock of the target Bluetooth device using the FHS packet received during inquiry.
• The paging device “pages” the target device with the target device’s device access code (DAC). The paging device transmits the DAC on several different hop frequencies that it thinks the target device is receiving (as calculated using the FHS packet) and continues to do so until a connection is made.
• While the paging device (the master) is paging, the target (slave) device may be involved in other piconets. Occasionally, it will enter the page scan state and listen for pages directed to it, scanning through 16 different frequencies. When it receives a page from the paging device, it will respond to the page by sending an update of its clock to the paging device.
• Once the paging device receives a page response from the target device, information vital for a connection is exchanged between the two devices. Information exchanged includes the device address and clock of the paging device, which is used to determine the timing and frequency-hop sequence of the newly formed piconet. When all connection information has been communicated, the connection is complete, and the two devices can begin to exchange data with one another.
Bluetooth packet format:
Since Bluetooth is meant to be compatible with many different applications, it must be able to send data with different protocols quickly and efficiently. When data is transmitted at the lowest level, it is first broken down into smaller packets and sent serially with the least significant bit sent first. Each data packet (represented in Figure 2) contains three fields: an access code, a header, and a payload.
Access codes
At the beginning of each Bluetooth packet is an access code. The access code is used primarily for piconet identification and synchronization. The access code identifies the piconet to which each data packet belong; all data packets having both a packet header and payload present will have a 72-b access code; otherwise, the access code is 68-b long. Access codes are also used extensively in Bluetooth with no header or payload present. The access code itself (Figure 3) is divided into three sections-preamble, sync word, and trailer-which are not present in inquiry or device access codes.
Packet header
The packet header, which follows the access code and contains page link control information, co9ntain six fields: AM_ADDR, TYPE, FLOW, ARON, SEQN, and HEC (Figure 4).
• AM_ADDR, a 3-b active member address, is used to indicate where the packet is destined. When a slave receives a data packet, it checks the packet header’s AM_ADDR. If it matches its own assigned AM_ADDR, the packet will be decoded; otherwise, it is discarded.
• The 4-b TYPE field indicates the type of packet that has been sent. There are up to 16 different types of Bluetooth packets.
• The FLOW bit is used for flow control. For example, if the receive (RX) buffer of a recipient device is full, it will indicate in its response to the master that it cannot accept any data at that moment. Once it can receive more data, the FLOW bit is changed from 0 to 1.
• ARQN is the acknowledge bit that informs the source whether the previous transaction was successful.
• The sequence (SEQN) bit allows the source and the recipient to keep track of the packets that have been sent. The bit is inverted on each packet transmission and used to prevent the reception of packets that may have been sent twice. Repeat transmission of a packet occurs when the acknowledgement signal of a successful data transaction to the master fails to transmit. The receiving device can simply compare the SEQN bit of the packet that was previously processed to determine whether to discard or accept the packet.
• The header error check, HEC, is used to check the integrity and accuracy of the header during each packet transaction. If the HEC is incorrect, the packet is discard. While the header comprises 18 b, the fact that it is encoded at a rate of one-third the forward error correction (FEC) rate, extends the total bit length to 54 b.
• The payload , which follows the header, can range from 0 to 2,745 b, and contains the actual data of interest. With a packet capable of being sent during every 625 micro second time slot, a maximum bit rate of 723.2 kb/s can be achieved for an ACL, and 64 kb/s can be achieved for an ACL, and 64 kb/s for an SCO.
Bluetooth can handle the transmission of many different applications. This entails dealing with different architectural layers to decompose the application data into a form suitable for transmission over a Bluetooth link, as well as to reassemble the data into its original form at the receiving end.
GENERAL BLUETOOTH ARCHITECHTURE
Facilitating this data transmission is a series of protocols within the Bluetooth system that processes the data for suitable transmission and receipt.
The general structure of a Bluetooth system consists of a microprocessor that handles all the baseband specifications, and several software layers that structure the data so that it may be sent properly over a Bluetooth link. Figure 5 provides a good representation of the architecture.
At the highest architecture level lies the different communication and data information protocols that can communicate over the Bluetooth link, including wireless application protocol (WAP), user datagram protocol (UDP), transport control protocol (TCP), internet protocol (IP), and point-to-point protocol (PPP). While all of these are standalone communication protocols, they can be adapted for transmission over a Bluetooth link. To support these different types of communication protocols, the Bluetooth system architecture must be capable of capable of differentiating and converting data associated with these protocols into data packets that the Bluetooth baseband controller and RF transceiver can send.
One of the protocols within the Bluetooth architecture that is responsible for this adaptation is RFCOMM, which emulates a serial port and can be used by applications that use the serial ports on a Bluetooth device. RFCOMM can take the data from some of the higher level protocols mentioned previously and adapt it so it can be sent down to the baseband and converted into Bluetooth data packets and subsequently sent over a Bluetooth link.
Below RFCOMM lies the logical page link control and adaptation protocol (L2CAP) that further supports the adaptation of other communication protocols, such as telephony control specification binary (TCS-binary) and the Bluetooth-established service discovery protocol (SDP), as well as performing the multiplexing between all incoming upper-level protocols (RFCOMM, TCS, SDP), as well as performing the multiplexing between all incoming upper-level protocols (RFCOMM, TCS, SDP). In addition to protocol multiplexing, L2CAP is responsible for the segmentation of outgoing data packets so they may be transferred to the baseband processor cannot handle data packets of great size. L2CAP is also responsible for the reassembly of received data packets, which are subsequently sent to one of the higher-level protocols designated to receive this data.
Once the original data has been segmented by L2CAP into subsequent L2CAP packets, the packets are then sent to the host controller interface (HCI), which is responsible for sending data to and receiving data from the lower level Bluetooth hardware (baseband controller) through a physical bus (USB, RS232, PCI), HCI further alters the L2CAP packets so that the data may be transported over one of the physical buses. This data is received by the page link manager and baseband controller that assemble it into packets that are communicable using a Bluetooth link.
At the lowest level lie the page link manager and baseband controller. The baseband controller performs all low level processing, such as Bluetooth packet composition for transmission and packet decomposition upon reception. Running on the baseband controller is firmware implementing the page link manager protocol, which handles page link control, is responsible for placing the device in low power states, and performs any encryption of the data transmitted.
PRANEETH SURAPANENI
NAVYA PUTUMBAKA
[attachment=10311]
ABSTRACT
The seemingly endless entanglement of data wires connecting today’s electronic devices has become slightly less jumbled with the introduction of Bluetooth technology and the creation of a wireless data link. This article delves into the implementation and architecture of Bluetooth. It also describes the functional overview and applications of Bluetooth. It gives significant advantages of Bluetooth over other data transfer technologies such as IrDA and Home RF. It illustrates how a
connection is made in Bluetooth between two environments. It mainly emphasizes the architecture of Bluetooth. It gives over all Bluetooth packet structure and different communication and data information protocols such as WAP, UDP, IP,TCP ,RFCOMM, L2CAP etc. It also explains Link Security by Data Encryption. Finally it narrates how Bluetooth will bring a new level of connectivity and convenience when operating electronic devices. These details in the article establish the growing need for Bluetooth technology.
INTRODUCTION
Bluetooth is a method for data communication that uses short-range radio links to replace cables between computers and their connected units. Bluetooth is a radio frequency technology utilizing the unlicensed 2.5GHz industrial, scientific and medical (ISM) band. Bluetooth is an open standard for wireless connectivity with supporters mostly from the PC and cell phone industries. Not surprisingly, its primary market is for data and voice transfer between communication devices and PCs. Bluetooth was invented by L.M.Ericson of Sweden in 1994. The standard is named after Harald Blaatand"Bluetooth"2nd,king of Denmark.
WHY BLUETOOTH?
Bluetooth attempts to provide significant advantages over other data transfer technologies such as IrDA and HomeRF. IrDA is already popular in PC to peripherals,but is severely limited by the short connection distance of 1m and the line of sight requirement for communication. Due to its RF nature bluetooth is not subjected to such limitations. In addition to wireless device connections up to 10-100m, devices need not be within line of sight. Also it is designed to be low cost i.e under $10/unit.
Establishing a connection in Bluetooth:
Linking one Bluetoooth device to another to another involves a series of inquiry and paging procedures. The inquiry process entails the following steps:
• The Bluetooth device sends out an inquiry access code packet (inquiry packet) to search and locate these devices.
• The existing Bluetooth devices already within the area (and usually unware of any inquiring devices) will occasionally enter an inquiry scan state of their own to troll for any inquiring devices.
• When a device in the inquiry scan state receives an inquiry packet, it will respond with a frequency hop synchronization (FHS) packet that is sent back to the inquiring device.
Once the inquiry routine is completed, the paging process follows:
• The inquiring Bluetooth device now wants to establish a connection with another Bluetoooth device.
• To successfully locate and page a target Bluetooth device, the paging device estimates the hop frequency and clock of the target Bluetooth device using the FHS packet received during inquiry.
• The paging device “pages” the target device with the target device’s device access code (DAC). The paging device transmits the DAC on several different hop frequencies that it thinks the target device is receiving (as calculated using the FHS packet) and continues to do so until a connection is made.
• While the paging device (the master) is paging, the target (slave) device may be involved in other piconets. Occasionally, it will enter the page scan state and listen for pages directed to it, scanning through 16 different frequencies. When it receives a page from the paging device, it will respond to the page by sending an update of its clock to the paging device.
• Once the paging device receives a page response from the target device, information vital for a connection is exchanged between the two devices. Information exchanged includes the device address and clock of the paging device, which is used to determine the timing and frequency-hop sequence of the newly formed piconet. When all connection information has been communicated, the connection is complete, and the two devices can begin to exchange data with one another.
Bluetooth packet format:
Since Bluetooth is meant to be compatible with many different applications, it must be able to send data with different protocols quickly and efficiently. When data is transmitted at the lowest level, it is first broken down into smaller packets and sent serially with the least significant bit sent first. Each data packet (represented in Figure 2) contains three fields: an access code, a header, and a payload.
Access codes
At the beginning of each Bluetooth packet is an access code. The access code is used primarily for piconet identification and synchronization. The access code identifies the piconet to which each data packet belong; all data packets having both a packet header and payload present will have a 72-b access code; otherwise, the access code is 68-b long. Access codes are also used extensively in Bluetooth with no header or payload present. The access code itself (Figure 3) is divided into three sections-preamble, sync word, and trailer-which are not present in inquiry or device access codes.
Packet header
The packet header, which follows the access code and contains page link control information, co9ntain six fields: AM_ADDR, TYPE, FLOW, ARON, SEQN, and HEC (Figure 4).
• AM_ADDR, a 3-b active member address, is used to indicate where the packet is destined. When a slave receives a data packet, it checks the packet header’s AM_ADDR. If it matches its own assigned AM_ADDR, the packet will be decoded; otherwise, it is discarded.
• The 4-b TYPE field indicates the type of packet that has been sent. There are up to 16 different types of Bluetooth packets.
• The FLOW bit is used for flow control. For example, if the receive (RX) buffer of a recipient device is full, it will indicate in its response to the master that it cannot accept any data at that moment. Once it can receive more data, the FLOW bit is changed from 0 to 1.
• ARQN is the acknowledge bit that informs the source whether the previous transaction was successful.
• The sequence (SEQN) bit allows the source and the recipient to keep track of the packets that have been sent. The bit is inverted on each packet transmission and used to prevent the reception of packets that may have been sent twice. Repeat transmission of a packet occurs when the acknowledgement signal of a successful data transaction to the master fails to transmit. The receiving device can simply compare the SEQN bit of the packet that was previously processed to determine whether to discard or accept the packet.
• The header error check, HEC, is used to check the integrity and accuracy of the header during each packet transaction. If the HEC is incorrect, the packet is discard. While the header comprises 18 b, the fact that it is encoded at a rate of one-third the forward error correction (FEC) rate, extends the total bit length to 54 b.
• The payload , which follows the header, can range from 0 to 2,745 b, and contains the actual data of interest. With a packet capable of being sent during every 625 micro second time slot, a maximum bit rate of 723.2 kb/s can be achieved for an ACL, and 64 kb/s can be achieved for an ACL, and 64 kb/s for an SCO.
Bluetooth can handle the transmission of many different applications. This entails dealing with different architectural layers to decompose the application data into a form suitable for transmission over a Bluetooth link, as well as to reassemble the data into its original form at the receiving end.
GENERAL BLUETOOTH ARCHITECHTURE
Facilitating this data transmission is a series of protocols within the Bluetooth system that processes the data for suitable transmission and receipt.
The general structure of a Bluetooth system consists of a microprocessor that handles all the baseband specifications, and several software layers that structure the data so that it may be sent properly over a Bluetooth link. Figure 5 provides a good representation of the architecture.
At the highest architecture level lies the different communication and data information protocols that can communicate over the Bluetooth link, including wireless application protocol (WAP), user datagram protocol (UDP), transport control protocol (TCP), internet protocol (IP), and point-to-point protocol (PPP). While all of these are standalone communication protocols, they can be adapted for transmission over a Bluetooth link. To support these different types of communication protocols, the Bluetooth system architecture must be capable of capable of differentiating and converting data associated with these protocols into data packets that the Bluetooth baseband controller and RF transceiver can send.
One of the protocols within the Bluetooth architecture that is responsible for this adaptation is RFCOMM, which emulates a serial port and can be used by applications that use the serial ports on a Bluetooth device. RFCOMM can take the data from some of the higher level protocols mentioned previously and adapt it so it can be sent down to the baseband and converted into Bluetooth data packets and subsequently sent over a Bluetooth link.
Below RFCOMM lies the logical page link control and adaptation protocol (L2CAP) that further supports the adaptation of other communication protocols, such as telephony control specification binary (TCS-binary) and the Bluetooth-established service discovery protocol (SDP), as well as performing the multiplexing between all incoming upper-level protocols (RFCOMM, TCS, SDP), as well as performing the multiplexing between all incoming upper-level protocols (RFCOMM, TCS, SDP). In addition to protocol multiplexing, L2CAP is responsible for the segmentation of outgoing data packets so they may be transferred to the baseband processor cannot handle data packets of great size. L2CAP is also responsible for the reassembly of received data packets, which are subsequently sent to one of the higher-level protocols designated to receive this data.
Once the original data has been segmented by L2CAP into subsequent L2CAP packets, the packets are then sent to the host controller interface (HCI), which is responsible for sending data to and receiving data from the lower level Bluetooth hardware (baseband controller) through a physical bus (USB, RS232, PCI), HCI further alters the L2CAP packets so that the data may be transported over one of the physical buses. This data is received by the page link manager and baseband controller that assemble it into packets that are communicable using a Bluetooth link.
At the lowest level lie the page link manager and baseband controller. The baseband controller performs all low level processing, such as Bluetooth packet composition for transmission and packet decomposition upon reception. Running on the baseband controller is firmware implementing the page link manager protocol, which handles page link control, is responsible for placing the device in low power states, and performs any encryption of the data transmitted.
