Page 489 - From GMS to LTE

Bluetooth and Bluetooth Low Energy 475

layer, which is called RFCOMM and which is accessed with PSM 0x0003. RFCOMM
offers a virtual serial interface to services and thus simplifies data transfer.
How these serial interfaces are used depends on the higher‐layer service that makes
use of the connection. The ‘serial port’ service, for example, uses the RFCOMM layer to
offer a virtual serial interface to any non‐Bluetooth application. From the application’s
point of view, there is no difference between a virtual serial interface and a separate,
physical serial interface. Usually, the operating system assigns COM port 3, 4, 5, 6, etc.
to the Bluetooth serial interfaces. Which COM port numbers are used is decided during
the installation of the Bluetooth stack on the device. Before Wi‐Fi tethering became
popular, these serial interfaces were then used during the installation of a new modem
driver for the Windows DUN functionality. When an application such as Windows
DUN used the modem driver to establish a connection, the Bluetooth stack opened a
connection to the remote device. This process could be performed automatically if the
Bluetooth stack was previously assigned a certain COM port number to a specific
remote device.
To simulate a complete serial interface, the RFCOMM layer simulates not only the
transmit and receive lines but also the status lines, such as the Request to Send (RTS),
Clear to Send (CTS), Data Terminal Ready (DTR), Data Set Ready (DSR), Data Carrier
Detect (CD) and Ring Indicator (RI). In a physical implementation of a serial interface,
these lines are handled by a UART chip. Thus, the Bluetooth serial port service simu-
lates a complete UART chip. A real UART chip translates the commands of the applica-
tion layer into signal changes on physical lines. The virtual Bluetooth UART chip on the
other hand translates higher‐layer commands into RFCOMM packets, which are then
forwarded to the L2CAP layer.
RFCOMM is also used by other services, such as the file transfer service (Object
Exchange (OBEX)) that is still in use today. Using different RFCOMM channel num-
bers, it is possible to select during connection establishment which of the services to
communicate with. The channel number is part of the service description in the SDP
database. For example, if a device asks the service database of a remote Bluetooth device
for the parameters of the OBEX service, the remote device will reply that the service
uses the L2CAP and RFCOMM layers to provide its service. Thus, the device will establish
an L2CAP connection by using PSM 0x0003 to establish a connection to the RFCOMM
layer (L2CAP to RFCOMM). Furthermore, the database entry contains the RFCOMM
channel number so that the device can connect to the correct higher‐layer service. As
the RFCOMM number can be assigned dynamically, the service database has to be
queried during each new connection establishment to the service.
Figure 7.13 shows how different layers multiplex simultaneous data streams. While
the HCI layer multiplexes the connections to several remote devices (connection
handles), the L2CAP layer is responsible for multiplexing several data streams to
different services per device (PSM and CID). This is used in practice to differentiate
between requests to the service database (PSM 0x0001) and the RFCOMM layer
(PSM 0x0003). Apart from the service database, many Bluetooth services use the
RFCOMM layer and thus can be distinguished only because they use different
RFCOMM channel numbers.
The RFCOMM channel number also allows the use of up to 30 RFCOMM services
between two devices simultaneously. Thus, it is possible during a dial‐up connection to
establish a second connection to transfer files via the OBEX service. As both services