Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Bluetooth Protocol Stack

[Top]


Purpose

This document provides a brief overview of the architecture of the Symbian OS Bluetooth subsystem.

In this overview

The Bluetooth architectural overview is split into two sections : The Bluetooth Stack and Bluetooth Protocols. The stack and protocol will be discussed in terms of how they are implemented in the Symbian OS Bluetooth subsystem. This means there will be cross references provided to the appropriate Bluetooth Profiles and when appropriate and to the Bluetooth components or APIs in which the Layer or protocol is used.


The Bluetooth Stack

Like many other communications technologies Bluetooth is composed of a hierarchy of components referred to as a stack. The stack is shown below:

Figure 1. The Symbian OS Bluetooth stack


Figure 1. The Symbian OS Bluetooth stack

In Bluetooth parlance Host more or less means software and Controller more or less means hardware. The Host Controller Interface (HCI) driver provides the host layers with access to the hardware layers (not shown) of the Bluetooth stack.

The protocols presented in the above stack are discussed in the following section.

[Top]


Bluetooth Protocols

The Bluetooth specification identifies and defines the protocols that must be and may be present within a Bluetooth compliant device. Both L2CAP and RFCOMM, discussed below, are datalink protocols. SDP is a session protocol. BNEP is a networking protocol. AVDTP and AVCTP are session protocols.


L2CAP

The Logical Link Control And Adaptation Protocol (L2CAP) manages the link over which all higher protocols communicate. It controls how multiple users of the physical Bluetooth link are multiplexed together, handles packet segmentation and reassembly (SAR), and conveys quality of service information. As of Symbian OS version 8.1, L2CAP also provides channel error and flow control as well as improved SAR handling. L2CAP is part of the Generic Access Profile and its functionality is implemented in the Bluetooth User component.

Profile Component

GAP

Bluetooth USER

L2CAP data packets communicate over a port, there are approximately 30000 L2CAP ports. An application simply makes a request for a free port (the application should register the port in the SDP record). L2CAP can handle multiple channels running over the same port.


RFCOMM

RFCOMM allows an application to treat a Bluetooth link in a similiar way as if it were communicating over an RS232 serial port. Applications can use the RFCOMM protocol but usually it is better to go directly to an L2CAP connection. The primary advantage RFCOMM has to offer over L2CAP is the RS232 emulation. But that is really only an advantage when creating a Bluetooth connection for an application that expects an RS232 connection, so legacy applications. RFCOMM also offers guarenteed flow control to each service. Since RFCOMM is running over an L2CAP connection its usefulness for new applications needs to be carefully considered. Refer to the Bluetooth specification for more details.

Another difference between L2CAP and RFCOMM is the range of ports available for applications. While L2CAP provides a large range of ports RFCOMM has only 30.

Profile Component

GAP

Bluetooth CSY

Bluetooth USER

The Bluetooth CSY API, which uses C32 APIs, is used to support legacy applications.


SDP

The Service Discovery Protocol (SDP) is used for locating and describing services provided by or available through a Bluetooth device. Applications typically use it when they are setting up communications to another Bluetooth device.

Profile Component

GAP

Bluetooth SDP


Link Manager

The Bluetooth Link Manager protocol provides direct control and notification of ACL and SCO logical transports. This allows for role switching and allows greater control of packet size on the baseband layer. The link manager protocol also provides a mechnaism for handling hardware failures.

Profile Component

GAP

Bluetooth User

The Link Manager belongs to GAP and through GAP is also used by all other profiles. All Bluetooth links need management.


BNEP

The Bluetooth Network Encapsulation Protocol (BNEP) defines a packet format, based on EthernetII/DIX Framing (IEEE 802.3), which provides for a stable network environment across a Bluetooth connection over L2CAP.

Profile Component

PAN profile.

Bluetooth PAN Profile

BNEP transports networking protocols over an L2CAP channel.


Audio Video Control and Distribution Protocols

The AV control protocol supports AVRCP Bluetooth Headset profile as well as the Bluetooth Remote Control Profile and the AV distribution protocol supports the GAVDP profile.

AVCTP

The Audio Video Control Transport Protocol defines a format for sending Audio video control commands over a Bluetooth connection.

Profile Component

Audio Video Remote Control Profile (AVRCP).

Bluetooth Remote Control Framework

AVCTP and AVRCP, working with AVDTP and GAVDP, enable the Bluetooth Remote Control Framework and more specifically the Bluetooth headset usecase.

AVDTP

The Audio Video Distribution Transport Protocol provides a transport of encoded multimedia packets over Bluetooth.

Profile Component

Generic Audio Video Distribution Profile (GAVDP).

GAVDP APIs

AVDTP supports packing and transport of audio data. These data packets are then propogated through the stack over an L2CAP channel to a receiving device.