|
|||||||||||||||||||
|
advertisement |
|
Bluetooth Seattle broadens the user experience through a transparent mix of technologies Feb 1, 2008 12:00 PM By Mark E. Hazen As this special EWT section unfolds, improvements in ultrawideband (UWB) wireless and ultralow-power Bluetooth, it sheds light on the integration of UWB technology into Bluetooth specifications. It also describes solutions that bring the benefits of this integration to consumer and mobile communications products.
The Bluetooth Seattle architectureFigure 1 proposes how the WiMedia UWB radio may be merged with the Bluetooth system core under a common host. In this hybrid architecture, UWB layers are available for use under the control of the Bluetooth higher layers in the host. The UWB PAL serves as a translator between the application profile management entity plus L2CAP and the WiMedia MAC. Other radios could also be used. UWB is just one of the Bluetooth Seattle AMP, another one being the 802.11 radio. It is the intention of Bluetooth SIG to expand the specification in such a way that other radios can be added in the future with a PAL for each. The blue blocks of Figure 1 define the hardware and embedded firmware of the Bluetooth controller. The controller is a building block that contains three layers in hardware and firmware. At the lowest layer is the 2.4 GHz radio front-end — the next is the baseband layer — then the link manager layer. Physical medium layer: consists of the radio front-end, which converts frame bits to analog symbols that are carried at some radio frequency, or frequencies. For Bluetooth, the symbols are created using GFSK or M-ary PSK carried by RF energy in an adaptive, or dynamic, frequency-hopping scheme composed from a selection of 79 channels. The adaptive nature of the frequency hopping provides a means of avoiding interference. In the UWB radio (green), OFDM is used. It is a scheme in which many evenly spaced carriers are orthogonally modulated using some multiple of QPSK or DCM. Bluetooth baseband layer: includes the link controller and baseband resource manager along with a device manager (not shown). The link controller encodes and decodes packets based upon the data and parameters related to the physical channel, logical transport and logical link. The baseband resource manager has two primary functions: 1) schedule and grant time on the physical channel for all sources that have requested access; and 2) negotiate access contracts with the sources, which establishes the QoS for each source. The device manager controls the behavior of the Bluetooth device and plays a key role in the discovery of other devices. Link manager layer: uses LMP to establish, modify and release logical links between Bluetooth devices. The link manager in each device works together to establish link status. It contains HCI firmware. The HCI firmware is used to form a bridge to the host via the HCI driver in the host. The HCI is used to ensure that the Bluetooth controller remains generic, as a standard part, and can be associated and controlled by any host. The Bluetooth protocol defines host controller interfaces, which enable the stack to be cleanly divided between the host processor and the Bluetooth controller chip(s). The Bluetooth v2.1+EDR HCIs are UART, SDIO and USB. These will be expanded in the new specification to ensure there are HCIs that can handle the high data rates of UWB. HostL2CAP: crossing the physical bus to the host is the logical link control and adaptation layer protocol running on the host processor. In many products, radio chip(s) are under the direction of a host processor, where the majority of the software for the system is run. In this case, the Bluetooth con-troller is assumed to have limited data-buffering capabilities in comparison with the host. Therefore, the L2CAP layer is expected to carry out simple resource management when submitting packets to the controller for transport to a peer device. This includes segmentation into manageable sizes suitable for the controller buffers and organization into start and continuation packets, plus management of the use of the controller buffers to ensure availability for channels with QoS commitments. Application profile management: manages services, which cover items like service discovery, connection and association along with profiles. The Bluetooth profiles define the possible applications, i.e., HID, A2DP and FTP. Bluetooth profiles are general behaviors through which Bluetooth-enabled devices communicate with other devices. A range of profiles describe different types of use cases. At a minimum, each profile specification contains information about its dependency on other profiles: suggested user-interface formats and the specific parts of the Bluetooth protocol stack used (each profile uses particular options and parameters at each layer of the stack). UWB radioMAC: linked to the host via the UWB protocol adaptation layer, is the WiMedia MAC. The MAC and managers provide synchronization and error control (ACK, REQ) to make communications possible between devices. After discovery and synchronization, the MAC and managers of communicating devices must exchange control messages to configure and manage the baseband MAC/PHY. Physical layer (PHY): PHY layer of the UWB radio is part of the baseband processor. Forward error correction is added here and modulation takes place to form QPSK or DCM symbols on a large number of individual carriers (OFDM). Radio front-end: used to mix the OFDM spectrum to move it from baseband to a range between 6 and 9 GHz. Bringing it all togetherThe Bluetooth controller, L2CAP and profiles are used for device discovery, service discovery, error recovery and physical layer discovery to establish a UWB connection. The Bluetooth system is used to re-establish the UWB link if it is broken. By using a UWB PAL, the WiMedia MAC/PHY radio can be mated with and controlled by the Bluetooth system, making use of the range of Bluetooth profiles available. The Bluetooth system will handle all traffic unless it is discovered that a very high data rate is needed. The service is passed seamlessly to UWB only as long as it is needed. Bluetooth Seattle will retain the advantages of previous generations with the guarantee of backward compatibility while enabling the UWB functionality that leads to new high-speed applications. Low-power consumption will be preserved because the low-power Bluetooth BR/EDR side of the solution will be in control and will offer the high-speed capability only when it is needed. ABOUT THE AUTHORMark E. Hazen is an electronics engineer and professional technical writer. He is the editor for Emerging Wireless Technology.
Click here for the enhanced PDF version of this article |
|
||||||||||||||||
| Back to Top |