![Symbian Developer Library](../../../../../../a_stock/images/mainheading.gif)
![]() |
![]() |
|
This document provides a brief overview of the architecture of the Symbian OS Bluetooth subsystem.
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.
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
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.
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.
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 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.
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 |
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.
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.
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.
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.
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.