1. Distributed systems – Part 2  Bluetooth – 2 nd set of slides Anila Mjeda

2. 2 Bluetooth Specification Control Stack Radio Layer Baseband LCP LMP HCI L2CAP RFCOMM SDP

3. 3 Bluetooth Radio Layer  Modulates and demodulates data for transmission and reception on air  Is the lowest defined layer of the Bluetooth specification.  It defines the requirements & characteristics of the Bluetooth transceiver device.  Frequency bands (2.4 GHz) and channel arrangement (channel hopping)  Transmitter characteristics (including the output power of the radio, modulation characteristics)  Receiver characteristics (including sensitivity level)

4. 4 Baseband - 1/3  The Baseband is the physical layer of the Bluetooth. It lies on top of the Bluetooth radio layer in the Bluetooth stack. Is part of a device which controls the radio. It is responsible for low level timing, error control and management of the link within the domain of a single data packet transfer.  It manages physical channels and links. The baseband manages asynchronous and synchronous links, handles packets and does paging and inquiry to access and inquire Bluetooth devices in the area.  The baseband transceiver applies a time-division duplex (TDD) scheme. (alternate transmit and receive).

5. 5 Baseband - 2/3  Physical Channels The channels thought the which the Bluetooth device hops randomly in the 2.4 GHz ISM band - as discussed before  Physical Links  The Baseband handles two types of links : SCO (Synchronous Connection-Oriented) -> The SCO link is a symmetric point-to-point link between a master and a single slave in the piconet. Mainly used for voice. SCO packets are never retransmitted. ACL (Asynchronous Connection-Less) link -> The ACL link is a point-to-multipoint link between the master and all the slaves participating on the piconet. Only a single ACL link can exist. Packet retransmission is typical.

6. 6 Baseband -3/3  Packets All data on the piconet channel is conveyed in packets Diagram: Courtesy of Bluetooth SIG, Baseband Specs, Fig 4.1, p 47  Access Code -> used for timing synchronization, offset compensation, paging and inquiry. Three different types of Access code:  Channel Access Code (CAC): identifies a unique piconet  Device Access Code (DAC): used for paging and its responses  Inquiry Access Code (IAC): used for inquiry purposes.  Header-> Contains information for packet acknowledgement, packet numbering for out-of-order packet reordering, flow control, slave address and error check for header.  Payload ->can contain either voice field, data field or both. If it has a data field, the payload will also contain a payload header.

7. 7 Link Controller Protocol (LCP)  LCP configures and controls the baseband  Determines what packet is going to be sent next  Carries out higher level operations such as inquiry and paging  Manages multiple links between different devices and piconets  LCP does not use its own packets. Header bits in baseband packets are used to signal between link controllers

8. 8 Link Manager Protocol (LMP)  Responsible for security and link set-up between Bluetooth devices  The Link Manager carries out link setup, authentication, link configuration. It discovers other remote LM’s and communicates with them via the Link Manager Protocol (LMP). To perform its service provider role, the LM uses the services of the underlying Link Controller (LC).  The Link Manager Protocol essentially consists of a number of PDU (Protocol Data Units), which are sent from one device to another.  While we were talking about packets, at this layer we are talking about PDU-s

9. 9 Host Controller Interface (HCI)  Handles communication between a separate host and a Bluetooth module.  The HCI provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth baseband capabilities. The HCI exists across 3 sections, the Host - Transport Layer - Host Controller. Each of the sections has a different role to play in the HCI system. Host controller = the actual Bluetooth device Host = the software entity

10. 10 Host Controller Interface (HCI)

11. 11 Host Controller Interface (HCI)  HCI Firmware (location: Host Controller) HCI Firmware, is located on the Bluetooth 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 device  HCI Driver (location: Host) HCI Driver, is located in the host. 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.

12. 12 Logical Link Control and Adaptation (L2CAP)  Multiplexes data from higher layers, converts between different packet sizes  The Logical Link Control and Adaptation Layer Protocol (L2CAP) is layered over the Baseband Protocol and resides in the data link layer. L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length.  Two link types are supported for the Baseband layer: Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links support real-time voice traffic using reserved bandwidth. ACL links support best effort traffic.

13. 13 RFCOMM  Emulates an RS-232 like serial interface  RFCOMM is a simple transport protocol, which provides emulation of RS232 serial ports over the L2CAP protocol.  The RFCOMM protocol supports up to 60 simultaneous connections between two BT devices. The number of connections that can be used simultaneously in a BT device is implementation-specific. For the purposes of RFCOMM, a complete communication path involves two applications running on different devices (the communication endpoints) with a communication segment between them.

14. 14 Service Discovery Protocol - SDP  Lets Bluetooth devices discover what services other Bluetooth devices support The service discovery protocol (SDP) provides a means for applications to discover which services are available and to determine the characteristics of those available services.  A specific Service Discovery protocol is needed in the Bluetooth environment, as the set of services that are available changes dynamically based on the RF proximity of devices in motion, qualitatively different from service discovery in traditional network-based environments. The service discovery protocol defined in the Bluetooth specification is intended to address the unique characteristics of the Bluetooth environment. SDP does not define methods for accessing services; once services are discovered with SDP, they can be accessed in various ways, depending upon the service

15. 15 SDP in more detail  SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order.  In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given instant. In other words, a client must receive a response to each request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.

16. 16 SDP requests/response PDUs Diagram from Bluetooth SIG, SDP Specs, Fig 2.1, p 330

17. 17 Bibliography  Bluetooth tutorial: http://www.palowireless.com/infotoot h/tutorial.asp http://www.palowireless.com/infotoot h/tutorial.asp