Bluetooth technology has become an integral part of our daily lives, connecting a myriad of devices seamlessly across industries. Behind this seemingly magical connectivity lies a complex network of bluetooth protocols and layers. While L2CAP (Logical Link Control and Adaptation Protocol), which we have seen in the earlier article, serves as the foundation for Bluetooth communication, there are several bluetooth protocols stacked on top of it, each playing a crucial role in ensuring reliable and efficient data transmission. The L2CAP Bluetooth protocol stack layers explained in that article form the base upon which RFCOMM, OBEX, SDP, and TCS operate. In this blog, we will delve into these bluetooth protocols above L2CAP, unraveling their functionalities and exploring how they contribute to seamless Bluetooth networks.
Bluetooth Stack Overview
Before diving into the bluetooth protocols 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 bluetooth 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 bluetooth protocols. Here are some of the key layers and bluetooth protocols that operate above L2CAP.
| Layer | Description | Use Case |
|---|---|---|
| RFCOMM | 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)
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. RFCOMM is one of the most widely used bluetooth protocols for serial-based communication.
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 RFCOMM:
- 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 — hold, sniff, or park mode. RFCOMM can state its latency requirements to L2CAP; this information may be used by lower layers to decide which low power modes to use.
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. RFCOMM is also the underlying transport for multimedia on embedded systems that rely on serial-based audio channel control.
Service Discovery Protocol (SDP)
Service Discovery Protocol (SDP) is a simple Bluetooth 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 PDU and one response PDU.
| 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 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 connected Bluetooth devices. SDP supports 2 features — searching for service and browsing for service.
Searching for service:Allows a client to retrieve the service record handles for service records based on the UUID values of attributes contained within those service records.
Browsing for service:Creates a service search pattern containing the UUID that represents the root browse group.
The sdp protocol 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 without defining methods for accessing those services.
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.
Object Exchange Protocol (OBEX)
OBEX 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. OBEX works by exchanging objects used for a variety of purposes — establishing connection parameters, sending and requesting data, or changing the current path of a file.
OBEX is widely used in Bluetooth-enabled file transfer scenarios. The OBEX protocol supports object push, file transfer, and synchronization operations. OBEX transfers are governed by the same reliable transport guarantees provided by the underlying bluetooth protocols stack, ensuring data integrity during file exchange. In practice, OBEX enables the seamless sharing of contacts, images, and calendar entries between mobile devices.
Conclusion
The combined functionalities of bluetooth protocols like RFCOMM, SDP, OBEX, and TCS represent the backbone of Bluetooth technology, enabling seamless communication and interoperability across a wide range of devices and applications. Together these bluetooth protocols form a layered stack that makes cross-vendor Bluetooth integration reliable and predictable. Bluetooth defines higher-level application profiles that leverage these bluetooth protocols and provide uniform device implementations across vendors, which will be covered in the upcoming articles.