|
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
Page.
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
accommodate.
- 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…61. 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 L2CAP frame.
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.
Step 1:
- 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 established:
-
- 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.
Step 2:
- 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).
Step 3:
- 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…30. 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 session.
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 been established.
| Remote Port Negotiation (RPN) Command: |
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) Command: |
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 control mechanisms.
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 XON/XOFF
- Hardware flow control using RTS/CTS or DTR/DSR circuits.
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 control mechanisms.
- 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 characters).
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; e.g.
modems.
- 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 unacknowledged.
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 by RFCOMM.
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
platform.)
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 Specification.
|
