Bluetooth technology has become an integral part of our daily lives, connecting a myriad of devices seamlessly. Behind this seemingly magical connectivity lies a complex network of protocols and layers. While L2CAP (Logical Link Control and Adaptation Protocol), which we have seen in earlier article, serves as the foundation for Bluetooth communication, there are several protocols stacked on top of it, each playing a crucial role in ensuring reliable and efficient data transmission. In this blog, we will delve into these Bluetooth protocols above L2CAP, unraveling their functionalities and exploring how they contribute to the seamless operation of Bluetooth networks.

Bluetooth Stack Overview

Before diving into the layers above L2CAP, let's briefly recap the Bluetooth protocol stack with the picture below.

Higher level Bluetooth Protocols

At the lowest level, we have the Physical Layer, responsible for transmitting raw data over the air interface. Above it sits the Link Layer, which handles tasks such as device discovery, connection establishment, and error correction. L2CAP operates on top of the Link Layer and provides a multiplexing mechanism for higher-layer protocols. The coming sections will cover these higher-level Bluetooth protocols in detail.

Bluetooth Protocols Above L2CAP

Once data passes through L2CAP, it enters the realm of higher-layer protocols. Here are some of the key layers and protocols that operate above L2CAP.

Layer	Description	Use Case
RFCOM	Radio Frequency Communication	Audio Streaming
SDP	Service Discovery Protocol	Secure connection & Device Discovery and Sharing
TCS	Telephony Control Protocol Specification	Hands Free features (call and Multimedia controls)
OBEX	Object Exchange Protocol	File sharing and synchronization between Bluetooth devices

Let us explore these Bluetooth protocols one by one.

Radio Frequency Communication Protocol

RFCOMM emulates RS-232 control and data signals over the Bluetooth baseband and provides transport capabilities for higher-layer services that use a serial interface as a transport mechanism.

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 RFCOMM, a complete communication path involves two applications running on different devices (the communication endpoints) with a communication segment between them.

There are 2 types of devices supported in RFCOM

• Type 1 - Computers and printers
• Type 2 - Modems

At any time, there must be at most one RFCOMM session between any pair of devices. When establishing a new DLC, the initiating entity must check if there already exists an RFCOMM session with the remote device. A session is identified by the Bluetooth BD_ADDR of the two endpoints. RFCOMM must require L2CAP to provide channels with maximum reliability, to ensure that all frames are delivered in order, and without duplicates.

For better power consumption, if all L2CAP channels towards a certain device are idle for a certain amount of time, a decision may be made to put that device in a low power mode i.e hold, sniff or park mode. This will be done without any interference from RFCOMM. RFCOMM can state its latency requirements to L2CAP. This information may be used by lower layers to decide which low power mode(s) to use.

The RFCOMM protocol as such does not suffer from latency delays incurred by low power modes, and consequentially, this specification does not state any maximum latency requirement on RFCOMM’s behalf. Latency sensitivity inherently depends on application requirements, which suggests that an RFCOMM service interface implementation could include a way for applications to state latency requirements, to be aggregated and conveyed to L2CAP by the RFCOMM implementation.

Service Discovery Protocol

Service Discovery Protocol (SDP) is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport. 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.

Service record	Service is any entity that can provide information, perform an action, or control a resource on behalf of another entity. All the information about a service that is maintained by an SDP server is contained within a single service record
Service Attribute	It describes a single characteristic of a service. It contains the attribute type and value
Service Class	Each service is an instance of a service class. The service class definition provides the definitions of all attributes contained in service records that represent instances of that class

Service Discovery mechanism is used to identify the list of services offered by other or connected Bluetooth devices. It supports 2 features searching for service and browsing for service.

Searching for service: It allows a client to retrieve the service record handles for service records based on the values (UUID) of attributes contained within those service records. Values are basically universally unique identifiers (UUDI).

Browsing for service:It creates a service search pattern containing the UUID that represents the root browse group.

The Bluetooth Service Discovery Protocol (SDP) addresses service discovery specifically for the Bluetooth environment. It is optimized for the highly dynamic nature of Bluetooth communications. SDP focuses primarily on discovering services available from or through Bluetooth devices. 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/protocol.

Telephony Control Service Protocol

This protocol defines how to setup and control audio calls between Bluetooth devices. TCS is adapted from ITU-T Recommendation Q.931. Bluetooth also defines a subset of TCS called “lean TCS”. TCS BIN is the bit-oriented protocol that defines the call control signaling for the establishment of voice and data calls between Bluetooth devices. Additionally, TCS BIN defines mobility management procedures for handling groups of Bluetooth TCS devices. Bluetooth SIG has defined a set of AT commands to control mobile phones and modems in multiple usage models. FAX services commands are defined by the SIG.

Object Exchange Protocol (OBEX)

It is a session protocol developed by the Infrared Data Association (IrDA) to exchange objects in a simple and spontaneous manner. OBEX, which provides the same basic functionality as HTTP but in a much lighter fashion, uses a client-server model and is independent of the transport mechanism and transport API, provided it realizes a reliable transport base. It works by exchanging objects, which are used for variety of purposes such as establishing the parameters of a connection, sending and requesting data, changing the current path or the attribute of a file etc.

Conclusion

Combined functionalities of Bluetooth protocols like RFCOMM, SDP (service discovery protocol), OBEX, and the Telephony Control Protocol (TCS) represent the backbone of Bluetooth technology, enabling seamless communication and interoperability across a wide range of devices and applications. Bluetooth defines higher level application profiles that leverage these protocols and provides a uniform implementation of device functionalists across devices from different vendors, which will be covered in the upcoming articles.