RFCOMM Protocol

    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.

6.1  RFCOMM Overview/Service

   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.

6.1.1  Device Types

    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.

6.1.2  Control Signals

    RFCOMM emulates the 9 circuits of an RS-232 interface. The circuits are listed below.

6.1.3  Null Modem Emulation

    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.

6.1.4  Multiple Emulated Serial Ports

    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.

6.2  TS 07.10 Adaptations for RFCOMM

6.2.1  Media Adaption

    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.

6.2.2  TS 07.10 Multiplexer Startup & Closedown Procedure

    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.

 

6.2.3  DLCI Allocation with RFCOMM Server Channels

    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 session.

6.2.4  Multiplexer Control Commands

    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.

6.3  Flow Control Methods Used

    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.

6.3.1  L2CAP Flow Control

    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.

6.3.2  Wired Serial Port Flow Control

    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.

6.3.3  RFCOMM Flow Control

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.

6.3.4  Port Emulation Entity : Serial Flow Control

    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).

6.3.5  Credit Based Flow Control

    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.

6.4  Other Entity Interaction

6.4.1  Port Emulation and Port Proxy Entities

    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,

6.4.3  Service Registration and Discovery

    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).

6.4.3  Reliability

    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.

6.4.4  Low Power Modes

    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.