Bluetooth core system

 

The Bluetooth system consists  the Bluetooth core protocols , cable replacement(RFCOMM),telephony control protocols(HFP/HSP) and adopt protocols(OBEX/FTP/BIP etc).

 

1.Bluetooth core system.

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).

 

The architecture is shown in following Figure except for SDP that is not shown for clarity.

The layers are Radio layer,Baseband layer,Link manager layer,Logical link control and adapation protocol (L2CAP).

 

3.

 

The lowest three layers are sometimes grouped into a
subsystem known as the Bluetooth controller.

 

A service interface to the Bluetooth controller subsystem 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) and its
service access points are represented by the ellipses on the upper edge of the
Bluetooth controller subsystem in this Figure, and the implementation of
this standard service interface is optional.

 

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.

 

2 Bluetooth core system -- Bluetooth conrtoller subsystem

2.1 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.

 

2.2 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.

 

2.3 Device manager

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 devices, connecting to
other Bluetooth devices, or making the local Bluetooth device discoverable or
connectable by other devices.

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.

 

2.4 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.)

 

2.5 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.

 

2.6 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.

 

2.7 RF

The RF block is responsible for transmitting and receiving packets of information
on the physical channel.

 

3 Bluetooth core system -- Bluetooth host subsystem

3.1 Service Discovery Protocol (SDP)

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.

 

3.2 Generic Access Profile

The purpose of the Generic Access Profile is:
To introduce definitions, recommendations and common requirements related
to modes and access procedures that are to be used by transport and
application profiles.
To describe how devices are to behave in standby and connecting states in
order to guarantee that links and channels always can be established between
Bluetooth devices, and that multi-profile operation is possible. Special focus is
put on discovery, link establishment and security procedures.
To state requirements on user interface aspects, mainly coding schemes and
names of procedures and parameters, that are needed to guarantee a satisfactory
user experience.

 

4 Bluetooth core system -- Bluetooth Host Controller Interface

 

4.1 UART Transport Layer

The objective of this HCI UART Transport Layer is to make it possible to use
the Bluetooth HCI over a serial interface between two UARTs on the same
PCB.

 

4.2 USB Transport Layer

The USB Transport Layer is designed to take advantage Universal Serial Bus (USB)
interface for Bluetooth hardware.

 

4.3 SD Transport Layer

The Bluetooth SD transport interface specification is designed to take advantage
of both the SD Physical Transport bus and the packet orientation of the
Bluetooth HCI protocol.

 

4.4 Three-wire UART Transport Layer

The HCI Three-Wire UART Transport Layer is a connection based protocol that
transports HCI commands, events, ACL and Synchronous packets between
the Bluetooth Host and the Bluetooth Controller. Packet construction is in done
in two steps.

 

Done.