Bluetooth radio

https://qualweb.bluetooth.org/Building/HowTechnologyWorks/Architecture/Radio.htm

Bluetooth Radio

Scope

Bluetooth devices operate in the unlicensed 2.4 GHz ISM (Industrial Scientific Medical) band. A frequency hop transceiver is applied to combat interference and fading.Two modulation modes are defined. A mandatory mode, called Basic Rate, uses a shaped, binary FM modulation to minimize transceiver complexity. An optional mode, called Enhanced Data Rate, uses PSK modulation and has two variants: π/4-DQPSK and 8DPSK. The symbol rate for all modulation schemes is 1 Ms/s. The gross air data rate is 1 Mbps for Basic Rate, 2 Mbps for Enhanced Data Rate using π/4-DQPSK and 3 Mbps for Enhanced Data Rate using 8DPSK.For full duplex transmission, a Time Division Duplex (TDD) scheme is used in both modes. This specification defines the requirements for a Bluetooth radio for the Basic Rate and Enhanced Data Rate modes.

Frequency Bands and Channel Arrangement

The Bluetooth system operates in the 2.4 GHz ISM band. This frequency band is 2400 - 2483.5 MHz.The 79 RF channels are ordered from channel number 0-78 and are spaced 1 MHz beginning at 2402 GHz.Regulatory RangeRF Channels2.400-2.4835 GHzf=2402+k MHz, k=0,…,78In order to comply with out-of-band regulations in each country, a guard band is used at the lower and upper band edge.Lower Guard BandUpper Guard Band2 MHz3.5 MHz Power ClassesPower ClassMaximum OutputPower (Pmax)Nominal Output PowerMinimumOutput Power1Power Control1100 mW (20 dBm)N/A1 mW (0 dBm)Pmin <+4 dBm to PmaxOptional: Pmin2 to Pmax22.5 mW (4 dBm)1 mW (0 dBm)0.25 mW (-6 dBm)Optional: Pmin2 to Pmax31 mW (0 dBm)N/AN/AOptional: Pmin2 to Pmax 1. Minimum output power at maximum power setting.2. The lower power limit Pmin <- 30dBm is suggested but is not mandatory, and may be chosen according to application needs.Power class 1 devices implement power control. The power control is used for limiting the transmitted power over +4 dBm. Power control capability under +4 dBm is optional and could be used for optimizing the power consumption and overall interference level.Devices with power control capability optimizes the output power in a physical link with LMP commands (see Link Manager Protocol). It is done by measuring RSSI and reporting back if the transmission power shall be increased or decreased if possible.

Modulation Characteristics

The Modulation is GFSK (Gaussian Frequency Shift Keying) with a bandwidthbit period product BT=0.5.

Spurious Emissions

In-band spurious emissions shall be measured with a frequency hopping radio transmitting on one RF channel and receiving on a second RF channel; this means that the synthesizer may change RF channels between reception and transmission, but always returns to the same transmit RF channel. There will be no reference in this document to out of ISM band spurious emissions; the equipment manufacturer is responsible for compliance in the intended country of use.

Radio Frequency Tolerance

The transmitted initial center frequency shall be within ±75 kHz from Fc.

Enhanced Data Rate

A key characteristic of the Enhanced Data Rate mode is that the modulation scheme is changed within the packet. The access code and packet header, as defined in Table 6.1 in the Baseband Specification, are transmitted with the Basic Rate 1 Mbps GFSK modulation scheme, whereas the subsequent synchronization sequence, payload, and trailer sequence are transmitted using the Enhanced Data Rate PSK modulation scheme.

EDR Modulation Characteristics

During access code and packet header transmission the Basic Rate GFSK modulation scheme is used. During the transmission of the synchronization sequence, payload, and trailer sequence a PSK type of modulation with a data rate of 2 Mbps or optionally 3 Mbps is used.

Receiver Characteristics

Sensitivity Level

The actual sensitivity level is defined as the input level for which a raw bit error rate (BER) of 0.1% is met. The receiver sensitivity shall be below or equal to –70 dBm with any Bluetooth transmitter

Interference Performance

The interference performance on Co-channel and adjacent 1 MHz and 2 MHz shall be measured with the wanted signal 10 dB over the reference sensitivity level. For interference performance on all other RF channels the wanted signal shall be 3 dB over the reference sensitivity level.

Out-of-Band Blocking

The out-of-band suppression (or rejection) shall be measured with the wanted signal 3 dB over the reference sensitivity level. The interfering signal shall be a continuous wave signal. The BER shall be ≤ 0.1%.

Intermodulation Characteristics

The reference sensitivity performance, BER = 0.1%, shall be met under the following conditions:The wanted signal shall be at frequency f0 with a power level 6 dB over the reference sensitivity level.A static sine wave signal shall be at a frequency f1 with a power level of –39 dBm.A Bluetooth modulated signal (see Section 4.1.7 on page 43) shall be at f2 with a power level of -39 dBm.

Enhanced Data Rate 

EDR Actual Sensitivity Level

The actual sensitivity level shall be defined as the input level for which a raw bit error rate (BER) of 0.01% is met. The requirement for a Bluetooth π/4-DQPSK and 8DPSK Enhanced Data Rate receiver shall be an actual sensitivity level of –70 dBm or better. The receiver shall achieve the –70 dBm sensitivity level with any Bluetooth transmitter compliant to the Enhanced Data Rate transmitterspecification.

EDR BER Floor Performance

The receiver shall achieve a BER less than 0.001% at 10 dB above the reference sensitivity level.

Interference Performance

The interference performance for co-channel and adjacent 1 MHz and 2 MHz channels shall be measured with the wanted signal 10 dB above the reference sensitivity level. On all other frequencies the wanted signal shall be 3 dB above the refere

https://qualweb.bluetooth.org/Building/HowTechnologyWorks/Architecture/Overview.htm


Bluetooth SIG Shop | Bluetooth.comYou are not logged in Home | Register | LoginAbout UsMembershipBuilding with the TechnologyOverviewQualified Designs/ProductsProduct DevelopmentHow the Technology WorksCore SpecificationsArchitectureOverviewRadioBasebandLMPHCIL2CAPData TransportProfiles & ProtocolsSelect Language EnglishJapaneseKoreanSimplified ChineseSearch siteSearch 

Architecture: Overview

Core Architecture Blocks

Core System DefinitionBluetooth ControllerCore System Protocols and SignalingHost to Controller Interface (HCI): Splits BluetoothStack Into Controller and HostError Detection in L2CAP LayerTesting Interfaces: RF and Test Control Interface (TCI)Core Architecture BlocksChannel ManagerL2CAP Resource ManagerDevice ManagerLink ManagerBaseband Resource ManagerLink ControllerRF       

Core System Definition

The Bluetooth core system covers the four lowest layers and associated protocols defined by the Bluetooth specification as well as one common service layer protocol, the service discovery protocol (SDP) and the overall profile requirements are specified in the generic access profile (GAP). A complete Bluetooth application requires a number of additional services and higher layer protocols that are defined in the Bluetooth specification.To the top

Bluetooth Controller

The lowest three layers are sometimes grouped into a subsystem known as the Bluetooth controller. This is a common implementation involving a standard physical communications interface between the Bluetooth controller and remainder of the Bluetooth system including the L2CAP, service layers and higher layers (known as the Bluetooth host). Although this interface is optional, the architecture is designed to allow for its existence and characteristics. The Bluetooth specification enables interoperability between independent Bluetooth enabled systems by defining the protocol messages exchanged between equivalent layers, and also interoperability between independent Bluetooth sub-systems by defining a common interface between Bluetooth controllers and Bluetooth hosts.A number of functional blocks are shown and the path of services and data between these. The functional blocks shown in the diagram are informative; in general the Bluetooth specification does not define the details of implementations except where this is required for interoperability.To the top

Core System Protocols and Signaling

Standard interactions are defined for all inter-device operation, where Bluetooth devices exchange protocol signaling according to the Bluetooth specification. The Bluetooth core system protocols are the radio (RF) protocol, link control (LC) protocol, link manager (LM) protocol and logical link control and adaptation protocol (L2CAP), all of which are fully defined in subsequent parts of the Bluetoothspecification. In addition, the service discovery protocol (SDP) is a service layer protocol required by all Bluetooth applications.The Bluetooth core system offers services through a number of service access points that are shown in the diagram as ellipses. These services consist of the basic primitives that control the Bluetooth core system. The services can be split into three types. There are device control services that modify the behavior and modes of a Bluetooth device, transport control services that create, modify and release traffic bearers (channels and links), and data services that are used to submit data for transmission over traffic bearers. It is common to consider the first two as belonging to the C-plane and the last as belonging to the U-plane.To the top

Host to Controller Interface (HCI): Splits Bluetooth Stack Into Controller and Host

A service interface to the Bluetooth controller sub-system is defined such that the Bluetooth controller may be considered a standard part. In this configuration the Bluetooth controller operates the lowest three layers and the L2CAP layer is contained with the rest of the Bluetooth application in a host system. The standard interface is called the host to controller interface (HCI). Implementation of this standard service interface is optional.As the Bluetooth architecture is defined with the possibility of a separate host and controller communicating through an HCI, a number of general assumptions are made. The Bluetooth controller is assumed to have limited data buffering capabilities in comparison with the host. Therefore the L2CAP layer is expected to carry out some simple resource management when submitting L2CAP PDUs to the controller for transport to a peer device. This includes segmentation of L2CAP SDUs into more manageable PDUs and then the fragmentation of PDUs into start and continuation packets of a size suitable for the controller buffers, and management of the use of controller buffers to ensure availability for channels with quality of service (QoS) commitments.To the top

Error Detection in L2CAP Layer

The baseband layer provides the basic ARQ protocol in Bluetooth technology. The L2CAP layer can optionally provide a further error detection and retransmission to the L2CAP PDUs. This feature is recommended for applications with requirements for a low probability of undetected errors in the user data. A further optional feature of L2CAP is a window-based flow control that can be used to manage buffer allocation in the receiving device. Both of these optional features augment the QoS performance in certain scenarios.Although these assumptions may not be required for embedded Bluetooth technology implementations that combine all layers in a single system, the general architectural and QoS models are defined with these assumptions in mind, in effect a lowest common denominator.

Testing Interfaces: RF and Test Control Interface (TCI)

Automated conformance testing of implementations of the Bluetooth core system is required. This is achieved by allowing the tester to control the implementation through the RF interface, which is common to all Bluetooth systems, and through the test control interface (TCI), which is only required for conformance testing.The tester uses exchanges with the implementation under test (IUT) through the RF interface to ensure the correct responses to requests from remote devices. The tester controls the IUT through the TCI to cause the IUT to originate exchanges through the RF interface so that these can also be verified as conformant.The TCI uses a different command-set (service interface) for the testing of each architectural layer and protocol. A subset of the HCI command-set issued as the TCI service interface for each of the layers and protocols within the Bluetooth controller subsystem. A separate service interface is used for testing the L2CAP layer and protocol. As an L2CAP service interface is not defined in the Bluetoothcore specification it is defined separately in the TCI specification. Implementation of the L2CAP service interface is only required for conformance testing.To the top

Core Architecture Blocks

Channel Manager

The channel manager is responsible for creating, managing, and destroying L2CAP channels for the transport of service protocols and application data streams. The channel manager uses the L2CAP protocol to interact with a channel manager on a remote (peer) device to create these L2CAP channels and connect their endpoints to the appropriate entities. The channel manager interacts with its local link manager to create new logical links (if necessary) and to configure these links to provide the required QoS for the type of data being transported. 

L2CAP Resource Manager

The L2CAP resource manager block is responsible for managing the ordering of submission of PDU fragments to the baseband and some relative scheduling between channels to ensure that L2CAP channels with QoS commitments are not denied access to the physical channel due to Bluetooth controller resource exhaustion. This is required because the architectural model does not assume that the Bluetooth controller has limitless buffering, or that the HCI is a pipe of infinite bandwidth.L2CAP resource managers may also carry out traffic conformance policing to ensure that applications are submitting L2CAP SDUs within the bounds of their negotiated QoS settings. The general Bluetooth data transport model assumes well-behaved applications, and does not define how an implementation is expected to deal with this problem.

Device Manager

The device manager is the functional block in the baseband that controls the general behavior of the Bluetooth enabled device. It is responsible for all operation of the Bluetooth system that is not directly related to data transport, such as inquiring for the presence of other nearby Bluetooth enabled devices, connecting to other Bluetooth enabled devices or making the local Bluetooth enabled device discoverable or connectable by other devices.The device manager requests access to the transport medium from the baseband resource controller in order to carry out its functions.The device manager also controls local device behavior implied by a number of the HCI commands, such as managing the device local name, any stored link keys, and other functionality.

Link Manager

The link manager is responsible for the creation, modification, and release of logical links (and, if required, their associated logical transports), as well as the update of parameters related to physical links between devices. The link manager achieves this by communicating with the link manager in remote Bluetooth devices using the link management protocol (LMP).The LMP allows the creation of new logical links and logical transports between devices when required, as well as the general control of link and transport attributes such as the enabling of encryption on the logical transport, the adapting of transmit power on the physical link or the adjustment of QoS settings for a logical link.

Baseband Resource Manager

The baseband resource manager is responsible for all access to the radio medium. It has two main functions. At its heart is a scheduler that grants time on the physical channels to all of the entities that have negotiated an access contract. The other main function is to negotiate access contracts with these entities. An access contract is effectively a commitment to deliver a certain QoS that is required in order to provide a user application with an expected performance.The access contract and scheduling function must take account of any behavior that requires use of the Bluetooth radio. This includes, for example, the normal exchange of data between connected devices over logical links and logical transports, as well as the use of the radio medium to carry out inquiries, make connections, be discoverable or connectable, or to take readings from unused carriers during the use of AFH mode.In some cases the scheduling of a logical link results in changing to a different physical channel from the one that was previously used. This may be, for example, due to involvement in scatternet, a periodic inquiry function, or page scanning. When the physical channels are not time slot aligned, then the resource manager also accounts for the realignment time between slots on the original physical channel and slots on the new physical channel. In some cases the slots will be naturally aligned due to the same device clock being used as a reference for both physical channels.

Link Controller

The link controller is responsible for the encoding and decoding of Bluetooth packets from the data payload and parameters related to the physical channel, logical transport and logical link.The link controller carries out the link control protocol signaling (in close conjunction with the scheduling function of the resource manager), which is used to communicate flow control and acknowledgement and retransmission request signals. The interpretation of these signals is a characteristic of the logical transport associated with the baseband packet. Interpretation and control of the link control signaling is normally associated with the resource manager's scheduler.

RF

The RF block is responsible for transmitting and receiving packets of information on the physical channel. A control path between the baseband and the RF block allows the baseband block to control the timing and frequency carrier of the RF block. The RF block transforms a stream of data to and from the physical channel and the baseband into required formats.To the top © 2013 Bluetooth SIG all rights reserved print | site map | legal | privacy policy

http://www.qca.qualcomm.com/technology/technology.php?nav1=49&product=66