The RFCOMM protocol provides emulation of serial
ports over the L2CAP protocol. The protocol is
based on the ETSI standard TS 07.10. Only a subset of the TS 07.10
standard is used, and some adaptations of the protocol are specified in
the Bluetooth RFCOMM specification.
For more details: Download the RFCOMM
Specification from the SIG website, or visit the Documents
RFCOMM is a simple transport protocol, which provides
emulation of RS232 serial ports over the L2CAP protocol.The protocol is
based on the ETSI standard TS 07.10. Only a subset of the TS 07.10
standard is used and an RFCOMM - specific extension is added, in the form
of a mandatory credit based flow control scheme.
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 the
purposes of RFCOMM, a complete communication path involves two
applications running on different devices (the communication endpoints)
with a communication segment between them.
Basically two device types exist that RFCOMM must
- Type 1 Devices are communication end points such as
computers and printers.
- Type 2 Devices are those that are part of the
communication segment; e.g. modems.
Though RFCOMM does not make a distinction between
these two device types in the protocol, accommodating both types of
devices impacts the RFCOMM protocol.
The information transferred between two RFCOMM entities
has been defined to support both type 1 and type 2 devices. Some
information is only needed by type 2 devices while other information is
intended to be used by both. In the protocol, no distinction is made
between type 1 and type 2. Since the device is not aware of the type of
the other device in the communication path, each must pass on all
available information specified by the protocol.
RFCOMM emulates the 9 circuits of an RS-232
interface. The circuits are listed below.
|Pin Circuit Name
|102 Signal Common
|103 Transmit Data (TD)
|104 Received Data (RD)
|105 Request to Send (RTS)
|106 Clear to Send (CTS)
|107 Data Set Ready (DSR)
|108 Data Terminal Ready (DTR)
|109 Data Carrier Detect (CD)
|125 Ring Indicator (RI)
RFCOMM is based on TS 07.10. When it comes to
transfer of the states of the non-data circuits, TS 07.10 does not
distinguish between DTE and DCE devices. The RS-232 control signals are
sent as a number of DTE/DCE independent signals.
The way in which TS 07.10 transfers the RS-232
control signals creates an implicit null modem when two devices of the
same kind are connected together. No single null-modem cable wiring scheme
works in all cases; however the null modem scheme provided in RFCOMM
should work in most cases.
Two BT devices using RFCOMM in their communication
may open multiple emulated serial ports. RFCOMM supports up to 60 open
emulated ports; however the number of ports that can be used in a device
is implementation-specific. A Data Link Connection Identifier
(DLCI) identifies an ongoing
connection between a client and a server application. The DLCI is
represented by 6 bits, but its usable value range is 2?1. The DLCI is
unique within one RFCOMM session between two devices.
To account for the fact that both client and
server applications may reside on both sides of an RFCOMM session, with
clients on either side making connections independent of each other, the DLCI
value space is divided between the two communicating devices
using the concept of RFCOMM server channels.
If a BT device supports multiple emulated serial
ports and the connections are allowed to have endpoints in different BT
devices, then the RFCOMM entity must be able to run multiple TS 07.10
multiplexer sessions. Note that each multiplexer session is using its own L2CAP
channel ID (CID). The ability to run multiple sessions of the TS 07.10
multiplexer is optional for RFCOMM.
The opening flag and the closing flags in the 07.10
basic option frame are not used in RFCOMM, instead it is only the fields
contained between the flags that are exchanged between the L2CAP layer and
RFCOMM layer. There is always exactly one RFCOMM frame contained in each
The start-up and closedown procedures as specified
in section 5.7 in TS 07.10 are not supported.
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, and if so, establish the new DLC on that. A
session is identified by the Bluetooth BD_ADDR
of the two endpoints.
- Startup Procedure: The device opening up the first
emulated serial port connection between two devices is responsible for
first establishing the multiplexer control channel. This involves the
following steps, after which DLCs for user data traffic can be
- 1: Establish an L2CAP channel to the peer RFCOMM
entity, using L2CAP service primitives
- 2: Start the RFCOMM multiplexer by sending SABM
command on DLCI 0, and await UA response from peer entity.
- Closedown Procedure: The device closing the
last connection (DLC) on a particular session is responsible for
closing the multiplexer by closing the corresponding L2CAP channel.
- Closing the multiplexer by first sending a DISC command frame on
DLCI 0 is optional, but it is mandatory to respond correctly to a DISC
(with UA response).
- Link Loss Handling: If an L2CAP link loss
notification is received, the local RFCOMM entity is responsible for
sending a connection loss notification to the port emulation/proxy
entity for each active DLC. Then all resources associated with the
RFCOMM session should be freed.
To account for the fact that both client and server
applications may reside on both sides of an RFCOMM session, with clients
on either side making connections independent of each other, the DLCI
value space is divided between the two communicating devices using the
concept of RFCOMM server channels and a direction bit. The RFCOMM server
channel number is a subset of the bits in the DLCI part of the address
field in the TS 07.10 frame.
Server applications registering with an RFCOMM
service interface are assigned a Server Channel number in the range
1?0. For an RFCOMM session, the initiating device is given the
direction bit D=1 (and conversely, D=0 in the other device). When
establishing a new data link connection on an existing RFCOMM session, the
direction bit is used in conjunction with the Server Channel to determine
the DLCI to use to connect to a specific application. This DLCI is
thereafter used for all packets in both directions between the endpoints.
An RFCOMM entity making a new DLC on an existing
session forms the DLCI by combining the Server Channel for the application
on the other device, and the inverse of its own direction bit for the
Note that in TS 07.10, some
Multiplexer Control commands pertaining to specific DLCIs may be exchanged
on the control channel (DLCI 0) before the corresponding DLC has
|Remote Port Negotiation (RPN)
||The RPN command can be used before a new
DLC is opened and should be used whenever the port settings change.
|Remote Line Status (RLS) Command:
||This command is used for indication of
remote port line status.
|DLC Parameter Negotiation (PN)
||This is mandatory to use for RFCOMM
implementations conforming to the Bluetooth specification version
1.1 and later. This command must be used at least before
creation of the first DLC on an RFCOMM session, and the initiator
has to try to turn on the use of credit based flow control,
Wired ports commonly use flow control
such as RTS/CTS to control communications. On the other hand, the flow
control between RFCOMM and the lower layer L2CAP depends on the service
interface supported by the implementation. In addition RFCOMM has its own
flow control mechanisms. The following describes the different flow
L2CAP relies on the flow control mechanism provided
by the Link Manager layer in the
baseband. The flow control mechanism between the L2CAP and RFCOMM layers
is implementation specific.
Wired Serial port flow control falls into two camps
- Software flow control using characters such as
- Hardware flow control using RTS/CTS or DTR/DSR
These methods may be used by both sides of a wired
link, or may be used only in one direction.
The RFCOMM protocol provides two flow control mechanisms:
- The RFCOMM protocol contains flow control commands that operate on
the aggregate data flow between two RFCOMM entities;
i.e. all DLCIs are affected.
- The Modem Status command is the flow control mechanism that operates
on individual DLCI.
On Type 1 devices some port drivers (Port Emulation
Entities plus RFCOMM) will need to provide flow control services as
specified by the API they are emulating. An application may request a
particular flow control mechanism like XON/XOFF or RTS/CTS and expect the
port driver to handle the flow control.
On type 2 devices the port driver may need to
perform flow control on the non-RFCOMM part of the communication path;
i.e. the physical RS-232 port. This flow control is specified via the
control parameters sent by the peer RFCOMM entity (usually a type 1
device). The description of flow control in this section is for port
drivers on type 1 devices.
Since RFCOMM already has its own flow control
mechanism, the port driver does not need to perform flow control using the
methods requested by the application. In the ideal case, the application
sets a flow control mechanism and assumes that the COMM system will handle
the details. The port driver could then simply ignore the request and rely
on RFCOMM’s flow control. The application is able to send and receive
data, and does not know or care that the port driver did not perform flow
control using the mechanism requested. However, in the real world
some problems arise :
- The RFCOMM-based port driver is running on top of a packet-based
protocol where data may be buffered somewhere in the communication
path. Thus, the port driver cannot perform flow control with the same
precision as in the wired case.
- The application may decide to apply the flow control mechanism
itself in addition to requesting flow control from
the port driver.
These problems suggest that the port driver must do
some additional work to perform flow control emulation
properly. Here are the basic rules for flow control emulation.
- The port driver will not solely rely on the
mechanism requested by the application but use a combination of flow
- The port driver must be aware of the flow control mechanisms
requested by the application and behave like the wired case when it
sees changes on the non-data circuits (hardware flow control) or flow
control characters in the incoming data (software flow control). For
example, if XOFF and XON characters would have been stripped in the
wired case they must be stripped by the RFCOMM based port driver.
- If the application sets a flow control mechanism via the port driver
interface and then proceeds to invoke the mechanism on its own, the
port driver must behave in a manner similar to that of the wired case
(e.g. If XOFF and XON characters would have been passed through to the
wire in the wired case the port driver must also pass these
This is a mandatory feature that did not exist in
RFCOMM in Bluetooth specifications 1.0B and earlier. Therefore, its use is
subject to negotiation before the first DLC establishment. Implementations
conforming to this specification must support it, and must try to use it
when connecting to other devices.
The credit based flow control feature provides flow
control on a per - DLC basis. When used, both devices involved in a RFCOMM
session will know, for each DLC, how many RFCOMM frames the other device
is able to accept before it buffers fill up for that DLC. A sending entity
may send as many frames on a DLC as it has credits; if the credit count
reaches zero, the sender must stop and wait for further credits from the
peer. It is always allowed to send frames containing no user data (length
field = 0) when credit based flow control is in use. This mechanism
operates independently for each DLC, and for each direction. It does not
apply to DLCI 0 or to non-UIH frames.
This section defines how the RFCOMM protocol should
be used to emulate serial ports.
Type 1 devices are communication endpoints such as
computers and printers.Type 2 devices are part of a communication segment;
- Port Emulation Entity : The port emulation entity maps a
system specific communication interface (API) to the RFCOMM services.
- Port Proxy Entity : The port proxy entity relays data from
RFCOMM to an external RS-232 interface linked to a DCE. The
communications parameters of the RS-232 interface are set according to
received RPN commands,
Registration of individual applications or services,
along with the information needed to reach those (i.e. the RFCOMM Server
Channel) is the responsibility of each application respectively (or
possibly a Bluetooth configuration application acting on behalf of legacy
applications not directly aware of Bluetooth).
RFCOMM uses the services of L2CAP to establish L2CAP
channels to RFCOMM entities on other devices. An L2CAP channel is used for
the RFCOMM/TS 07.10 multiplexer session.
Some frame types (SABM and DISC) as well as UIH
frames with multiplexer control commands sent on DLCI 0 always require a
response from the remote entity, so they are acknowledged on the RFCOMM
level (but not retransmitted in the absence of acknowledgement ). Data
frames do not require any response in the RFCOMM protocol, and are thus
Therefore, RFCOMM must require L2CAP to provide
channels with maximum reliability, to ensure that all frames are delivered
in order, and without duplicates. Should an L2CAP channel fail to provide
this, RFCOMM will expect a link loss notification, which should be handled
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. (That is if such procedures make sense for a particular
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