Page 487 - From GMS to LTE

Bluetooth and Bluetooth Low Energy 473

application layer program. Optionally, it is now also possible to configure further
parameters for the connection by sending an L2CAP_Configuration_Request com-
mand. Such parameters are, for example, the maximum number of retransmission
attempts of a faulty packet and the maximum packet size that is supported by the device.
Another important task of the L2CAP layer is the segmentation of higher‐layer data
packets. This is necessary if higher‐layer packets exceed the size of ACL packets.
A five‐slot ACL packet, for example, has a maximum size of 339 bytes. If packets are
delivered from higher layers that exceed this size, they are split into smaller pieces and
sent in several ACL packets. Thus, the header of an ACL packet contains information
as to whether the packet includes the beginning of an L2CAP packet or whether the
ACL packet contains a subsequent segment. At the other end of the connection, the
L2CAP layer can then use this information to reassemble the L2CAP packet from
several ACL packets, which is then forwarded to the application layer.

7.4.6 The Service Discovery Protocol

Theoretically, it would be possible to begin the transfer of user data between two devices
right after establishing an ACL and L2CAP connection. Bluetooth, however, can be
used for many different applications, and many devices thus offer several different
services to remote devices at the same time. A mobile phone, for example, offers ser-
vices like wireless Internet connections (Dial‐up Network, DUN), file transfers to and
from the local file system, exchange of addresses and calendar entries, and so on. For a
device to detect which services are offered by a remote device and how they can be
accessed, each Bluetooth device contains a service database that can be queried by
other devices. The service database is accessed via L2CAP PSM 0x0001 and the proto-
col to exchange information with the database is called the Service Discovery Protocol
(SDP). The database query can be skipped if a device already knows how a remote
service can be accessed. As Bluetooth is very flexible, it offers services the option to
change their connection parameters at runtime. One of these connection parameters is
the RFCOMM channel number. More on this topic can be found in Section 7.4.7.
On the application layer, services are also called profiles. The headset service/headset
profile ensures that a headset interoperates with all Bluetooth‐enabled mobile phones
that also support the headset profile. More about Bluetooth profiles can be found in
Section 7.6.
Each Bluetooth service has its own universally unique identity (UUID) with which it
can be identified in the SDP database. The dial‐up server service, for example, has been
assigned UUID 0x1103. For the Bluetooth stack of a PC to be able to connect to this
service on a remote device like a mobile phone, the SDP database is queried at connec-
tion establishment and the required settings for the service are retrieved. For the dial‐
up server service, the database returns information to the requesting device that the
L2CAP and RFCOMM layers (see next section) have to be used for the service and also
informs the requester of the correct parameters to use.
The service database of a Bluetooth device furthermore offers a universal search
functionality. This is required to enable a device to discover all services offered by a
so‐far‐unknown device. The message sent to the database for a general search is called
an SDP_Service_Search_Request. Instead of a specific UUID as in the example above,
the UUID of the public browse group (0x1002) is used. The database then returns the