The Serial Port
Profile defines the requirements for Bluetooth devices necessary for
setting up emulated serial cable connections using RFCOMM between two peer
devices. The requirements are expressed in terms of services provided to
applications, and by defining the features and procedures that are
required for interoperability between Bluetooth devices.
Essentially, the Serial Port Profile defines
the protocols and procedures that shall be used by devices using Bluetooth
for RS232 (or similar) serial cable emulation.The scenario covered by this
profile deals with legacy applications using Bluetooth as a cable
replacement, through a virtual serial port abstraction (which in itself is
For more details : Download the K5
Specification from the SIG website, or visit the Documents
This profile defines how PPP
networking is supported in the following situations.
- LAN Access for a single Bluetooth device.
- LAN Access for multiple Bluetooth devices.
- PC to PC (using PPP networking over serial cable
The Baseband , LMP and
L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is
the Bluetooth adaptation of GSM TS 07.10 , providing a transport protocol
for serial port emulation. SDP is the Bluetooth Service Discovery Protocol
The port emulation layer is the
entity emulating the serial port, or providing an API to applications. The
applications on both sides are typically legacy applications, able and
wanting to communicate over a serial cable (which in this case is
emulated). But legacy applications cannot know about Bluetooth procedures
for setting up emulated serial cables, which is why they need help from
some sort of Bluetooth-aware helper application on both sides. (These
issues are not explicitly addressed in this profile; the major concern
here is for Bluetooth interoperability.)
The following roles are defined for this profile:
Device A (DevA)
This is the device that takes initiative to form a connection to
another device (DevA is the Initiator according to 'Configurations/Roles'
- Device B (DevB)
This is the device that waits for another device to take
initiative to connect. (DevB is the Acceptor according to
in GAP ). Note that the order of connection
(from DevA to DevB) does not necessarily have to have anything to do
with the order in which the legacy applications are started on each
The scenario covered by this
profile is the following:
- Setting up virtual serial ports (or equivalent) on
two devices (e.g. PCs) and connecting these with Bluetooth, to emulate
a serial cable between the two devices. Any legacy application may be
run on either device, using the virtual serial port as if there were a
real serial cable connecting the two devices (with RS232 control
This profile requires support for
one-slot packets only. This means that this profile ensures that data
rates up to 128 Kbps can be used. Support for higher rates is optional.
Only one connection at a time
is dealt with in this profile. Consequently, only point-to-point
configurations are considered. However, this should not be construed as
imposing any limitation on concurrence; multiple executions of this
profile should be able to run concurrently in the same device. This also
includes taking on the two different roles (as DevA and DevB)
For the execution of this
profile, use of security features such as authorisation, authentication
and encryption is optional. Support for authentication and encryption is
mandatory, such that the device can take part in the corresponding
procedures if requested from a peer device. If use of security features is
desired, the two devices are paired during the connection establishment
phase (if not earlier).
- Bonding is not explicitly used in this profile, and
thus, support for bonding is optional.
- Link establishment is initiated by DevA. Service
discovery procedures have to be performed to set up an emulated serial
- There are no fixed master slave roles.
- RFCOMM is used to transport the user data, modem
control signals and configuration commands.
When conformance to this
profile is claimed, all capabilities indicated mandatory for this profile
shall be supported in the specified manner (process-mandatory). This also
applies for all optional and conditional capabilities for which support is
indicated. All mandatory capabilities and optional and conditional
capabilities, for which support is indicated, are subject to verification
as part of the Bluetooth certification program.
This section describes the
feature requirements on units complying with the Serial Port profile. This
profile is built upon the Generic Access Profile (GAP) .
- When reading the GAP, the A-party (the connection
initiator) is equivalent to DevA and the B-party is equivalent to the
- All the mandatory requirements defined in GAP are
mandatory for this profile.
- Unless otherwise stated below, all the optional
requirements defined in GAP are optional for this profile.
Establish Link and Set up
Virtual Serial Connection: This procedure
refers to performing the steps necessary to establish a connection to an
emulated serial port (or equivalent) in a remote device. The steps in this
- Submit a query using SDP to find out the RFCOMM
Server channel number of the desired application in the remote
device.This might include a browsing capability to let the user select
among available ports (or services) in the peer device. Or, if it is
known exactly which service to contact, it is sufficient look up the
necessary parameters using the Service Class ID associated with the
- Optionally, require authentication of the remote
device to be performed. Also optionally, require encryption to be
- Request a new L2CAP channel to the remote RFCOMM
- Initiate an RFCOMM session on the L2CAP channel.
- Start a new data link connection on the RFCOMM
session, using the aforementioned server channel number.
After step 5, the virtual serial
cable connection is ready to be used for communication between
applications on both sides.
Accept link and
establish virtual serial connection: This procedure refers to taking
part in the following steps:
Register Service record in
local SDP database: This procedure refers
to registration of a service record for an emulated serial port (or
equivalent) in the SDP database. This implies the existence of a Service
Database, and the ability to respond to SDP queries.
- If requested by the remote device, take part in
authentication procedure and, upon further request, turn on
- Accept a new channel establishment indication from
- Accept an RFCOMM session establishment on that
- Accept a new data link connection on the RFCOMM
session. This may trigger a local request to authenticate the remote
device and turn on encryption, if the user has required that for the
emulated serial port being connected to (and authentication/encryption
procedures have not already been carried out ).
All services/applications reachable
through RFCOMM need to provide an SDP service record that includes the
parameters necessary to reach the corresponding service/application, see
Section 6.1. In order to support legacy applications running on virtual
serial ports, the service registration must be done by some
helper-application, which is aiding the user in setting up the port.
Mode & Link Loss Handling
Since the power requirements may be quite
different for units active in the Serial Port profile, it is not required
to use any of the power-saving modes. However, requests to use a low-power
mode shall, if possible, not be denied.
If sniff, park, or hold mode is used, neither RFCOMM
DLCs nor the L2CAP channel are released.
If a unit detects the loss of link, RFCOMM shall be
considered having been shut down. Before communication on higher layers
can be resumed, the Initialise RFCOMM session procedure has to be
This section describes the
requirements on RFCOMM in units complying with the Serial Port profile.
According to TS 07.10 ,
section 184.108.40.206.7, all devices are required to send information on all
changes in RS232 control signals with the Modem Status Command.
However, since RFCOMM can be used
with an adaptation layer implementing any kind of API (not only virtual
serial ports), it is optional to use all RS232 control signals except flow
control (the RTR signal in TS 07.10 ). This signal can be mapped on
RTS/CTS or XON/XOFF or other API mechanisms, which is an implementation
Line Status Indication
It is required to inform the
other device of any changes in RS232 line status with the Remote Line
Status indication command, if the local device relays information from a
physical serial port (or equivalent) where overrun-, parity- or
framing-errors may occur.
DevA may inform DevB of RS232
port settings with the Remote Port Negotiation Command, directly before
DLC establishment.There is a requirement to do so if the API to the RFCOMM
adaptation layer exposes those settings (e.g. baud rate, parity). DevB is
allowed to send the Remote Port Negotiation command.
The following text together
with the associated sub-clauses defines the mandatory requirements with
regard to this profile.
In this profile, only
connection-oriented channels shall be used. This implies that broadcasts
will not be used in this profile.
In the PSM field of the Connection
Request packet, the value for RFCOMM defined in the Assigned Numbers
document must be used.
Only DevA may issue an L2CAP
Connection Request within the execution of this profile. Other than that,
the Serial Port Profile does not impose any additional restrictions or
requirements on L2CAP signalling.
Maximum Transmission unit : This
profile does not impose any restrictions on MTU sizes over the
restrictions stated in the L2CAP spec (in section 6.1).
Flush Timeout : Serial
Port data is carried over a reliable L2CAP channel. The flush timeout
value shall be set to its default value 0xffff.
Quality of Service: Negotiation
of Quality of Service is optional in this profile.
There are no SDP Service Records related to
the Serial Port Profile in DevA.
To retrieve the service records in support of this
profile, the SDP client entity in DevA connects and interacts with the SDP
server entity in DevB via the SDP and L2CAP procedures presented in
sections 'Service Discovery'
and 'L2CAP' of SDAP
. In accordance to SDAP, DevA plays the role of the LocDev, while DevB
plays the role of the RemDev.
In addition to the requirements on supported
procedures stated in the Link Manager specification itself , this profile
also requires support for Encryption both in DevA and DevB.
If a unit tries to use a mandatory feature, and the
other unit replies that it is not supported, the initiating unit shall
send an LMP_detach with detach reason "unsupported LMP feature."
A unit shall always be able to handle the rejection
of the request for an optional feature.
There are no fixed master-slave roles for the
execution of this profile.
This profile does not state any requirements on
which low-power modes to use, or when to use them. That is up to the Link
Manager of each device to decide and request as seen appropriate, within
the limitations of the latency requirement.
inquiry is invoked in DevA, it shall use the General Inquiry procedure,
see in the 'Discoverability
Modes' in the GAP profile. Only DevA may inquire within the execution
of this profile.
For inquiry scan, (at least)
the GIAC shall be used, according to one of the discoverable modes defines
in GAP. That is, it is allowed to only use the Limited discoverable mode,
if appropriate for the application(s) residing in DevB.
In the DevB INQUIRY RESPONSE
messages, the Class of Device field will not contain any hint as to
whether DevB is engaged in the execution of the Serial Port Profile or
not. (This is due to the fact the generalised Serial Port service for
legacy applications delivered by this profile does not fit within any of
the major Service Class bits in the Class Of Device field definition.)
Only DevA may page within the
execution of this profile. The paging step will be skipped in DevA when
execution of this profile begins when there already is a baseband
connection between DevA and DevB. (In such a case the connection may have
been set up as a result of previous paging by DevB.)
most features on the LC level have to be activated by LMP procedures,
errors will mostly be caught at that layer. However, there are some LC
procedures that are independent of the LMP layer, e.g. inquiry or paging.
Misuse of such features is difficult or sometimes impossible to detect.
There is no mechanism defined to detect or prevent such improper use.
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth