RFCOMM with TS 07.10 Serial Port Emulation

RFCOMM is a simple transport protocol, with additional provisions for emulating the 9 circuits of RS-232 (EIATIA-232-E) serial ports.

The RFCOMM protocol supports up to 60 simultaneous connections between two Bluetooth devices. The number of connections that can be used simultaneously in a Bluetooth 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. Figure 1.1 shows the complete communication path. (In this context, the term application may mean other things than end-user application; e.g. higher layer protocols or other services acting on behalf of end-user applications.)

Figure 1.1. RFCOMM Communication Segment

RFCOMM is intended to cover applications that make use of the serial ports of the devices in which they reside. In the simple configuration, the communication segment is a Bluetooth link from one device to another (direct connect), see Figure 1.2. Where the communication segment is another network, Bluetooth wireless technology is used for the path between the device and a network connection device like a modem. RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case. RFCOMM can support other configurations, such as modules that communicate via Bluetooth wireless technology on one side and provide a wired interface on the other side, as shown in Figure 1.3.

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.

Figure 1.2. RFCOMM Direct Connect

Figure 1.3. RFCOMM used with legacy COMM device

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. It is therefore up to the RFCOMM implementers to determine if the information passed in the RFCOMM protocol is of use to the implementation. 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.

This document uses the same byte ordering as the TS 07.10 specification; i.e. all binary numbers are in Least Significant Bit to Most Significant Bit order, reading from left to right.

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

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, see Table 2.2.

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. Figure 2.1 shows the null modem that is created when two DTE are connected via RFCOMM. No single null-modem cable wiring scheme works in all cases; however the null modem scheme provided in RFCOMM should work in most cases.

Figure 2.1. RFCOMM DTE–DTE Null Modem Emulation

The figure below shows a model of how RFCOMM fits into a typical system. This figure represents the RFCOMM reference model.

Figure 3.1. RFCOMM reference model

The elements of the RFCOMM reference model are described below.

RFCOMM uses the basic option of TS 07.10.

Table 4.1 shows the TS 7.10 frame types that are supported in RFCOMM.

The ’Unnumbered Information (UI) command and response’ are not supported by RFCOMM. Since the error recovery mode option of the TS 07.10 protocol is not used in RFCOMM none of the associated frame types are supported.

TS 07.10 defines a multiplexer that has a dedicated control channel, DLCI 0. The control channel is used to convey information between two multiplexers. The following commands in TS 07.10 are supported by RFCOMM:

Whenever a non-supported command type is received a ’Non-Supported Command Response (NSC)’ should be sent.

RFCOMM only supports the type 1 convergence layer in TS 07.10.

The Modem Status Command (MSC) shall be used to convey the RS-232 control signals and the break signal for all emulated serial ports.

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, see Figure 5.1.

There is always exactly one RFCOMM frame contained in each L2CAP frame.

Figure 5.1. Frame Structure for Basic option. Note that the opening and closing flags from the 07.10 Basic option are excluded in RFCOMM.

The start-up and closedown procedures as specified in section 5.7 in TS 07.10 are not supported. This means that the AT-command AT+CMUX is not supported by RFCOMM, neither is the multiplexer close down (CLD) command.

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^[1].

Table 5.1 contains all the applicable system parameters for the RFCOMM implementation of the TS 07.10 multiplexer.

Since RFCOMM relies on lower layers to provide reliable transmission, the default action performed on timeouts is to close down the multiplexer session.

On the responding side, if authentication procedures are triggered from RFCOMM, this must only be done when receiving a SABM frame, not when receiving configuration commands preparing an unopened DLC.

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. [0 and 31 should not be used since the corresponding DLCIs are reserved in TS 07.10] It is this value that should be registered in the Service Discovery Database, see Section 7.2.

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.

In effect, this partitions the DLCI value space such that server applications on the non-initiating device are reachable on DLCIs 2,4,6,…,60; and server applications on the initiating device are reachable on DLCIs 3,5,7,…,61. (Note that for a device that supports multiple simultaneous RFCOMM sessions to two or more devices, the direction bit might not be the same on all sessions.)

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.

DLCI 1 and 62-63 are reserved and never used in RFCOMM.

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. (This refers the PN and RPN commands.) All such states associated with an individual DLC must be reset to their default values upon receiving a DISC command frame, or when closing the DLC from the local side. This is to ensure that all DLC (re-)establishments on the same session will have predictable results, irrespective of the session history.

If a Multiplexer Control command is received relating to a DLCI that is not open, the responding implementation may replace the "proper" response on the Multiplexer Control channel with a DM frame, sent on the referenced DLCI to indicate that the DLCI is not open, and that the responder would not grant a request to open it later either. (That is, a subsequent SABM sent by initiator would be declined with DM again.)

In GSM TS 07.10, it is stated in section 5.4.6.1 that it is allowed it is allowed to include multiple multiplexer control messages in one frame (as long as the maximum frame size is not exceeded). This feature is disallowed in RFCOMM. (But it is still allowed for an RFCOMM entity to issue multiple multiplexer control messages, each in its own frame, without waiting for responses in between).

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 ports falls into two camps – software flow control using characters such as XON/XOFF, and 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 GSM TS 07.10 protocol provides two flow control mechanisms:

Note that these flow control mechanisms only relate to the flow of user payload data in UIH frames on DLCIs other than the multiplexer control channel (DLCI 0). Also note that it is mandatory to support these GSM TS 07.10-styles of flow control, in order to maintain backward compability with Bluetooth version 1.0B.

When MSC commands are used^[2], it is only the FC bit that affects the flow on the RFCOMM protocol level. The RTR bit (along with the other V.24 signals in the MSC command) must only be treated transparently as “information” by the RFCOMM entity.

See also figure 3.1. The V.24 signals carry information between the port emulation entities on behalf of applications, and may also be interpreted as “flow control” information as described in the section on Port Emulation Entity Serial Flow Control 6.4, if negotiation has been done with the RPN command.

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.

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.

These basic rules are applied to emulate each of the wired flow control schemes. Note that multiple types of flow control can be set at the same time. Section 5.4.8 in ref [1] defines each flow control mechanism.

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 (see Section 5.5.3 and Section 6.5.1). 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.5.2. DLC Operation

When credit based flow control is being used, the meaning of the P/F bit in the control field of the RFCOMM header is redefined for UIH frames.

When the P/F-bit is zero in a UIH-frame, the frame is structured according to Figure 5.1.

When the P/F-bit is one in a UIH-frame, the frame is structure according to Figure 6.1 below. In this case, a credit field is inserted between the length indicator and the payload information field. The value of the credit octet (0 - 255)signifies a number of frames, for which the sender now has buffer space available to receive on the DLC. (Each frame may be sized up to agreed maximum frame size). Credits are additive, meaning that received credits are added to whatever remaining credits that may be left from before. In this case, the length indicator field (as always) indicates the number of information octets in the following information field; however, the maximum number of allowable information octets is decreased by one to compensate for the credit field. (This is to keep the maximum L2CAP payload size constant). This means, that for UIH-frames with the P/F-bit = 0, the maximum size of the information field is the negotiated one (= the N1 parameter), whereas for UIH-frames with the P/F-bit = 1, the actual maximum size is one less (N1 - 1).

Figure 6.1. Frame Structure for Basic option, UIH frames with P/F-bit = 1 and credit based flow control used. Note that the opening and closing flags from 07.10 Basic option are excluded in RFCOMM.

This section defines how the RFCOMM protocol should be used to emulate serial ports. Figure 7.1 shows the two device types that the RFCOMM protocol supports.

Figure 7.1. The RFCOMM communication model

Type 1 devices are communication endpoints such as computers and printers. Type 2 devices are part of a communication segment; e.g. modems.

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

Below is a template/example for developing service records for a given service or profile using RFCOMM. It illustrates the inclusion of the ServiceClassList with a single service class, a ProtocolDescriptor List with two protocols (although there may be more protocols on top of RFCOMM). The example shows the use of one other universal attribute (ServiceName). For each service running on top of RFCOMM, appropriate DP-defined universal attributes and/or service-specific attributes will apply. For additional information on Service Records, see the SDP Specification, Section 2.2 on page 340.

The attributes that a client application needs (at a minimum) to connect to a service on top of RFCOMM are the ServiceClassIDList and the ProtocolDescriptorList (corresponding to the shaded rows in the table below).

Notes: