882019 rfcomm

httpslidepdfcomreaderfullrfcomm 132

Part F1

RFCOMM with TS 0710

Serial Port Emulation

This document specifies the RFCOMM proto-

col by specifying a subset of the ETSI TS 0710standard along with some Bluetooth-specific

adaptations

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 232

394 5 June 2003

BLUETOOTH SPECIFICATION Version 11 page 394 of 1084

RFCOMM with TS 0710

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 232

394 5 June 2003

BLUETOOTH SPECIFICATION Version 11 page 394 of 1084

RFCOMM with TS 0710

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 332

5 June 2003 395

BLUETOOTH SPECIFICATION Version 11 page 395 of 1084

RFCOMM with TS 0710

CONTENTS

1 Introduction 39911 Overview 399

12 Device Types 399

13 Byte Ordering400

2 RFCOMM Service Overview 401

21 RS-232 Control Signals401

22 Null Modem Emulation402

23 Multiple Emulated Serial Ports403231 Multiple Emulated Serial Ports between two Devices 403

232 Multiple Emulated Serial Ports and Multiple BluetoothDevices403

3 Service Interface Description405

31 Service Definition Model 405

4 TS 0710 Subset Supported by RFCOMM 406

41 Options and Modes406

42 Frame Types 406

43 Commands406

44 Convergence Layers407

5 TS 0710 Adaptations for RFCOMM40851 Media Adaptation 408

511 FCS calculation408

512 PF-Bit(Erratum 1053) 408

513 CR bit(Erratum 1510) 409

52 TS 0710 Multiplexer Start-up and Closedown Procedure 410521 Start-up procedure410

522 Close-down procedure 410

523 Link loss handling411

53 System Parameters412

54 DLCI allocation with RFCOMM server channels413

55 Multiplexer Control Commands414551 Remote Port Negotiation Command (RPN) 414

552 Remote Line Status Command (RLS)415

553 DLC parameter negotiation (PN)415

6 Flow Control 417

61 L2CAP Flow Control in Overview417

62 Wired Serial Port Flow Control417

63 (Erratum 1549)GSM TS 0710 Flow Control417

64 Port Emulation Entity Serial Flow Control 419

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 432

396 5 June 2003

BLUETOOTH SPECIFICATION Version 11 page 396 of 1084

RFCOMM with TS 0710

65 Credit based flow control(Erratum 1053) 420651 Initial DLC Negotiation(Erratum1053) 420

652 DLC Operation(Erratum1053)420

653 Other flow control aspects(Erratum1053) 421

7 Interaction with Other Entities422

71 Port Emulation and Port Proxy Entities422711 Port Emulation Entity422

712 Port Proxy Entity 422

72 Service Registration and Discovery422

73 Lower Layer Dependencies 424731 Reliability424

732 Low power modes424

8 References425

9 Terms and Abbreviations 426

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 532

Introduction 5 June 2003 397

BLUETOOTH SPECIFICATION Version 11 page 397 of 1084

RFCOMM with TS 0710

1 INTRODUCTION

The RFCOMM protocol provides emulation of serial ports over the L2CAP pro-

tocol The protocol is based on the ETSI standard TS 0710 This documentdoes not contain a complete specification Instead references are made to therelevant parts of the TS 0710 standard Only a subset of the TS 0710 stan-dard is used and some adaptations of the protocol are specified in this docu-ment Furthermore an RFCOMM - specific extension is added in the form of amandatory credit based flow control scheme

11 OVERVIEW

RFCOMM is a simple transport protocol with additional provisions for emulat-

ing the 9 circuits of RS-232 (EIATIA-232-E) serial ports

The RFCOMM protocol supports up to 60 simultaneous connections betweentwo Bluetooth devices The number of connections that can be used simulta-neously in a Bluetooth device is implementation-specific

12 DEVICE TYPES

For the purposes of RFCOMM a complete communication path involves twoapplications running on different devices (the communication endpoints) with acommunication segment between them Figure 11 shows the complete com-munication path (In this context the term application may mean other thingsthan end-user application eg higher layer protocols or other services actingon behalf of end-user applications)

Figure 11 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 communica-tion segment is a Bluetooth link from one device to another (direct connect)see Figure 12 Where the communication segment is another network Blue-tooth wireless technology is used for the path between the device and a net-work connection device like a modem RFCOMM is only concerned with theconnection between the devices in the direct connect case or between thedevice and a modem in the network case RFCOMM can support other config-urations such as modules that communicate via Bluetooth wireless technologyon one side and provide a wired interface on the other side as shown in Figure

Application

Device A

Application

Device B

Communication

Segment

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 632

398 5 June 2003 Introduction

BLUETOOTH SPECIFICATION Version 11 page 398 of 1084

RFCOMM with TS 0710

13 These devices are not really modems but offer a similar service They aretherefore not explicitly discussed here

Basically two device types exist that RFCOMM must accommodate Type 1

devices are communication end points such as computers and printersType 2 devices are those that are part of the communication segment egmodems Though RFCOMM does not make a distinction between these twodevice types in the protocol accommodating both types of devices impacts theRFCOMM protocol

Figure 12 RFCOMM Direct Connect

Figure 13 RFCOMM used with legacy COMM device

The information transferred between two RFCOMM entities has been definedto support both type 1 and type 2 devices Some information is only needed bytype 2 devices while other information is intended to be used by both In theprotocol 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 theRFCOMM protocol is of use to the implementation Since the device is notaware of the type of the other device in the communication path each mustpass on all available information specified by the protocol

13 BYTE ORDERING

This document uses the same byte ordering as the TS 0710 specification ieall binary numbers are in Least Significant Bit to Most Significant Bit orderreading from left to right

Device A

with BT

(Type 1)

Device B

with BT

(Type 1)

BT

Device A

with BT

(Type 1)

Device B

with BT

(Type 2)

Device C

non BT

BT Wir e

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 732

RFCOMM Service Overview 5 June 2003 399

BLUETOOTH SPECIFICATION Version 11 page 399 of 1084

RFCOMM with TS 0710

2 RFCOMM SERVICE OVERVIEW

RFCOMM emulates RS-232 (EIATIA-232-E) serial ports The emulation

includes transfer of the state of the non-data circuits RFCOMM has a built-inscheme for null modem emulation

In the event that a baud rate is set for a particular port through the RFCOMMservice interface that will not affect the actual data throughput in RFCOMMie RFCOMM does not incur artificial rate limitation or pacing However if either device is a type 2 device (relays data onto other media) or if data pacingis done above the RFCOMM service interface in either or both ends actualthroughput will on an average reflect the baud rate setting

RFCOMM supports emulation of multiple serial ports between two devices and

also emulation of serial ports between multiple devices see Section 23 onpage 401

21 RS-232 CONTROL SIGNALS

RFCOMM emulates the 9 circuits of an RS-232 interface The circuits are listedbelow

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)

Table 21 Emulated RS-232 circuits in RFCOMM

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 832

400 5 June 2003 RFCOMM Service Overview

BLUETOOTH SPECIFICATION Version 11 page 400 of 1084

RFCOMM with TS 0710

22 NULL MODEM EMULATION

RFCOMM is based on TS 0710 When it comes to transfer of the states of thenon-data circuits TS 0710 does not distinguish between DTE and DCE devices The RS-232 control signals are sent as a number of DTEDCE inde-pendent signals see Table 22

The way in which TS 0710 transfers the RS-232 control signals creates animplicit null modem when two devices of the same kind are connected togetherFigure 21 shows the null modem that is created when two DTE are connectedvia RFCOMM No single null-modem cable wiring scheme works in all caseshowever the null modem scheme provided in RFCOMM should work in mostcases

Figure 21 RFCOMM DTEndashDTE Null Modem Emulation

TS 0710 Signals Corresponding RS-232 Control Signals

RTC DSR DTR

RTR RTS CTS

IC RI

DV DCD

Table 22 TS 0710 Serial Port Control Signals

FG 1

TD 2

RD 3

RTS 4

CTS 5

DSR 6

SG 7

CD 8

DTR 20

RI 22

FG 1

TD 2

RD 3

RTS 4

CTS 5

DSR 6

SG 7

CD 8

DTR 20

RI 22

rsquoONrsquo

rsquoONrsquo

rsquoOFFrsquo

rsquoOFFrsquo

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 932

RFCOMM Service Overview 5 June 2003 401

BLUETOOTH SPECIFICATION Version 11 page 401 of 1084

RFCOMM with TS 0710

23 MULTIPLE EMULATED SERIAL PORTS

231 Multiple Emulated Serial Ports between two Devices

Two Bluetooth devices using RFCOMM in their communication may open mul-tiple emulated serial ports RFCOMM supports up to 60 open emulated portshowever the number of ports that can be used in a device is implementation-specific

A Data Link Connection Identifier (DLCI) [1] identifies an ongoing connectionbetween a client and a server application The DLCI is represented by 6 bitsbut its usable value range is 2hellip61 in TS 0710 DLCI 0 is the dedicated con-trol channel DLCI 1 is unusable due to the concept of Server Channels andDLCI 62-63 is reserved The DLCI is unique within one RFCOMM session

between two devices (This is explained further in Section 232) To account for the fact that both client and server applications may reside on both sides of anRFCOMM session with clients on either side making connections independentof each other the DLCI value space is divided between the two communicatingdevices using the concept of RFCOMM server channels This is further described in Section 54

Figure 22 Multiple Emulated Serial Ports

232 Multiple Emulated Serial Ports and Multiple Bluetooth Devices

If a Bluetooth device supports multiple emulated serial ports and the connec-tions are allowed to have endpoints in different Bluetooth devices then theRFCOMM entity must be able to run multiple TS 0710 multiplexer sessionssee Figure 23 Note that each multiplexer session is using its own L2CAPchannel ID (CID) The ability to run multiple sessions of the TS 0710 multi-plexer is optional for RFCOMM

RFCOMM

L2CAP

Baseband

612 3 hellip

RFCOMM

L2CAP

Baseband

612 3 hellip

Emulated serial ports

Radio

Emulated serial ports

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1032

402 5 June 2003 RFCOMM Service Overview

BLUETOOTH SPECIFICATION Version 11 page 402 of 1084

RFCOMM with TS 0710

Figure 23 Emulating serial ports coming from two Bluetooth devices

RFCOMM

L2CAP

Baseband

612 3 hellip 612 3 hellip

RFCOMM

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1132

Service Interface Description 5 June 2003 403

BLUETOOTH SPECIFICATION Version 11 page 403 of 1084

RFCOMM with TS 0710

3 SERVICE INTERFACE DESCRIPTION

RFCOMM is intended to define a protocol that can be used to emulate serial

ports In most systems RFCOMM will be part of a port driver which includes aserial port emulation entity

31 SERVICE DEFINITION MODEL

The figure below shows a model of how RFCOMM fits into a typical systemThis figure represents the RFCOMM reference model

Figure 31 RFCOMM reference model

The elements of the RFCOMM reference model are described below

Element Description

Application Applications that utilize a serial port communication interface

Port Emulation

Entity

The port emulation entity maps a system-specific communication

interface (API) to the RFCOMM services The port emulation entity

plus RFCOMM make up a port driver

RFCOMM Provides a transparent data stream and control channel over an

L2CAP channel Multiplexes multiple emulated serial ports

Service Registra-

tion Discovery

Server applications register here on local device and it provides ser-

vices for client applications to discover how to reach server applica-

tions on other devices

L2CAP Protocol multiplexing SAR

Baseband Baseband protocols defined by Bluetooth Specification

Data (TXRX)

Baseband

L2CAP

RFCOMM

PortEmulationEntity

Application

RFCOMM

Service Interface

Port Interface

(eg VCOMM)

Service

registrationdiscovery

Readwrite Control

Generalcontrol parameters

Port parameter settings

SDP

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1232

404 5 June 2003 TS 0710 Subset Supported by RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 404 of 1084

RFCOMM with TS 0710

4 TS 0710 SUBSET SUPPORTED BY RFCOMM

41 OPTIONS AND MODESRFCOMM uses the basic option of TS 0710

42 FRAME TYPES

Table 41 shows the TS 710 frame types that are supported in RFCOMM

The rsquoUnnumbered Information (UI) command and responsersquo are not supportedby RFCOMM Since the error recovery mode option of the TS 0710 protocol isnot used in RFCOMM none of the associated frame types are supported

43 COMMANDS

TS 0710 defines a multiplexer that has a dedicated control channel DLCI 0The control channel is used to convey information between two multiplexersThe following commands in TS 0710 are supported by RFCOMM

Whenever a non-supported command type is received a rsquoNon-Supported Com-mand Response (NSC)rsquo should be sent

Frame Types

Set Asynchronous Balanced Mode (SABM) command

Unnumbered Acknowledgement (UA) response

Disconnected Mode (DM) response

Disconnect (DISC) command

Unnumbered information with header check (UIH) command and response

Table 41 Supported frame types in RFCOMM

Supported Control Channel Commands

Test Command (Test)

Flow Control On Command (Fcon)

Flow Control Off Command (Fcoff)

Modem Status Command (MSC)

Remote Port Negotiation Command (RPN)

Remote Line Status (RLS)

DLC parameter negotiation (PN)

Non Supported Command Response (NSC)

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1332

TS 0710 Subset Supported by RFCOMM 5 June 2003 405

BLUETOOTH SPECIFICATION Version 11 page 405 of 1084

RFCOMM with TS 0710

44 CONVERGENCE LAYERS

RFCOMM only supports the type 1 convergence layer in TS 0710

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

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1432

406 5 June 2003 TS 0710 Adaptations for RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 406 of 1084

RFCOMM with TS 0710

5 TS 0710 ADAPTATIONS FOR RFCOMM

51 MEDIA ADAPTATIONThe opening flag and the closing flags in the 0710 basic option frame are notused in RFCOMM instead it is only the fields contained between the flags thatare exchanged between the L2CAP layer and RFCOMM layer see Figure 51

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

Figure 51 Frame Structure for Basic option Note that the opening and closing flags from the0710 Basic option are excluded in RFCOMM

511 FCS calculation

In 0710 the frame check sequence (FCS) is calculated on different sets of

fields for different frame types These are the fields that the FCS are calculatedon

For SABM DISC UA DM frames on Address Control and length field

For UIH frames on Address and Control field

(This is stated here for clarification and to set the standard for RFCOMM thefields included in FCS calculation have actually changed in version 700 of TS0710 but RFCOMM will not change the FCS calculation scheme from the oneabove)

512 PF-Bit

In the control field (see Figure 51 above) there is one bit denoted as the PF-bit The general function of this bit is explained in 0710 section 544 And thevalue to use for the PF-bit in IUH frames is further clarified in 0710 section5431 These rules apply without modification on an RFCOMM session wherethe credit based flow control scheme is not in use See Section 65

However when credit based flow control is in use the meaning of the PF-bit isredefined for UIH frames This also involves a redefinition of the frame struc-

ture compared to Figure 51 above See Section 652 for further details

Flag Address Control

Length

Indicator Information FCS Flag

0111

1101

1 octet 1 octet 1 or 2 octets Unspecified length

but integral number

of octets

1 octet 0111

1101

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1532

TS 0710 Adaptations for RFCOMM 5 June 2003 407

BLUETOOTH SPECIFICATION Version 11 page 407 of 1084

RFCOMM with TS 0710

513 CR bit

In GSM 0710 there are two different CR-bits one in the frame level (in theaddress field of the frame header) and one in the message level (in the com-

mand type field of the commands sent on the multiplexer control channel) TheCR bit in the frame level is set independently of the CR bit in the messagelevel

In the frame level the CR bit in the frame header is set as follows

bull For SABM UA DM and DISC frames CR bit is set according to Table 1 inGSM 0710 section 5212

bull For UIH frames the CR bit is always set according to section 5431 inGSM 0710 This applies independently of what is contained wthin the UIHframes either data or control messages

In the message level the CR bit in the command type field is set as stated insection 5462 in GSM 0710 Control messages are sent in UIH frames wherethe CR bit in the address field of the frame header is always set according tosection 5431 in GSM 0710 independently of whether the control message isa comand or a response

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1632

408 5 June 2003 TS 0710 Adaptations for RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 408 of 1084

RFCOMM with TS 0710

52 TS 0710 MULTIPLEXER START-UP AND CLOSEDOWNPROCEDURE

The start-up and closedown procedures as specified in section 57 in TS 0710are not supported This means that the AT-command AT+CMUX is not sup-ported 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 therealready exists an RFCOMM session with the remote device and if so establishthe new DLC on that A session is identified by the Bluetooth BD_ADDR of the

two endpoints1

521 Start-up procedure

The device opening up the first emulated serial port connection between twodevices is responsible for first establishing the multiplexer control channel Thisinvolves the following steps

bull Establish an L2CAP channel to the peer RFCOMM entity using L2CAP ser-vice primitives see L2CAP ldquoService Primitivesrdquo on page 303

bull Start the RFCOMM multiplexer by sending SABM command on DLCI 0 andawait UA response from peer entity (Further optional negotiation steps arepossible)

After these steps DLCs for user data traffic can be established

Implementation note There is a special case that may occur if two RFCOMMentities try to establish a session at the same time on an already existing base-band connection This will be experienced by an RFCOMM entity as receiving aL2CAP connect indication after it has itself issued a L2CAP connect request Inthis situation the RFCOMM entity should respond negatively to the receivedconnect indication (since there may only be one session between two RFCOMMentities) How the situation is resolved is up to the implementation (eg it mayretry after a random time or leave it up to the user to retry manually)

522 Close-down procedure

The device closing the last connection (DLC) on a particular session is respon-sible for closing the multiplexer by closing the corresponding L2CAP channel

Closing the multiplexer by first sending a DISC command frame on DLCI 0 isoptional but it is mandatory to respond correctly to a DISC (with UA response)

1 This implies that when responding to an L2CAP connection indication the RFCOMM entity

should save and associate the new RFCOMM session with the remote BD_ADDR This isat least necessary if subsequent establishment of a DLC in the opposite direction is possi-

ble (which may depend on device capabilities)

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1732

TS 0710 Adaptations for RFCOMM 5 June 2003 409

BLUETOOTH SPECIFICATION Version 11 page 409 of 1084

RFCOMM with TS 0710

523 Link loss handling

If an L2CAP link loss notification is received the local RFCOMM entity isresponsible for sending a connection loss notification to the port emulation

proxy entity for each active DLC Then all resources associated with theRFCOMM session should be freed

The appropriate action to take in the port emulationproxy entity depends onthe API on top For example for an emulated serial port (vCOMM) it would besuitable to drop CD DSR and CTS signals (assuming device is a DTE)

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1832

410 5 June 2003 TS 0710 Adaptations for RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 410 of 1084

RFCOMM with TS 0710

53 SYSTEM PARAMETERS

Table 51 contains all the applicable system parameters for the RFCOMMimplementation of the TS 0710 multiplexer

Note The timer T1 is the timeout for frames sent with the PF-bit set to one(this applies only to SABM and DISC frames in RFCOMM) T2 is the timeoutfor commands sent in UIH frames on DLCI 0 The exact timeout values areimplementation dependent and may be chosen within the ranges indicatedabove However when sending SABM frame to start a new DLC (with DLCI ltgt0) and if there is no knowledge in the local RFCOMM entity that LMP authenti-cation has taken place on the link to the peer entity T1 must be set in the inter-val 60 - 300 seconds (Again with exact value being implementationdependent)

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

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

System Parameter Value

Maximum Frame Size (N1) Default 127 (negotiable range 23 ndash 32767)

Acknowledgement Timer (T1) 10-60 seconds Recommended value 20 seconds

See also note below

Response Timer for Multiplexer

Control Channel (T2)

10-60 seconds Recommended value 20 seconds

See also note below

Table 51 System parameter values

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 1932

TS 0710 Adaptations for RFCOMM 5 June 2003 411

BLUETOOTH SPECIFICATION Version 11 page 411 of 1084

RFCOMM with TS 0710

54 DLCI ALLOCATION WITH RFCOMM SERVER CHANNELS

To account for the fact that both client and server applications may reside onboth sides of an RFCOMM session with clients on either side making connec-tions independent of each other the DLCI value space is divided between thetwo 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 0710 frame

Server applications registering with an RFCOMM service interface are assigned aServer Channel number in the range 1hellip30 [0 and 31 should not be used sincethe corresponding DLCIs are reserved in TS 0710] It is this value that should beregistered in the Service Discovery Database see Section 72

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 linkconnection on an existing RFCOMM session the direction bit is used in con-

junction with the Server Channel to determine the DLCI to use to connect to aspecific application This DLCI is thereafter used for all packets in both direc-tions between the endpoints

In effect this partitions the DLCI value space such that server applications onthe non-initiating device are reachable on DLCIs 246hellip60 and server appli-cations on the initiating device are reachable on DLCIs 357hellip61 (Note thatfor 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 andthe inverse of its own direction bit for the session

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

Bit No 1 2 3 4 5 6 7 8

TS 0710 EA CR DLCI

RFCOMM EA CR D Server Channel

Table 52 The format of the Address Field

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2032

412 5 June 2003 TS 0710 Adaptations for RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 412 of 1084

RFCOMM with TS 0710

55 MULTIPLEXER CONTROL COMMANDS

Note that in TS 0710 some Multiplexer Control commands pertaining to spe-cific DLCIs may be exchanged on the control channel (DLCI 0) before the cor-responding DLC has been established (This refers the PN and RPNcommands) All such states associated with an individual DLC must be reset totheir default values upon receiving a DISC command frame or when closingthe DLC from the local side This is to ensure that all DLC (re-)establishmentson the same session will have predictable results irrespective of the sessionhistory

If a Multiplexer Control command is received relating to a DLCI that is notopen the responding implementation may replace the proper response onthe 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 arequest to open it later either (That is a subsequent SABM sent by initiator would be declined with DM again)

In GSM TS 0710 it is stated in section 5461 that it is allowed it is allowed toinclude multiple multiplexer control messages in one frame (as long as themaximum frame size is not exceeded) This feature is disallowed in RFCOMM(But it is still allowed for an RFCOMM entity to issue multiple multiplexer con-trol messages each in its own frame without waiting for responses inbetween)

551 Remote Port Negotiation Command (RPN)

The RPN command can be used before a new DLC is opened and should beused whenever the port settings change

The RPN command is specified as optional in TS 0710 but it is mandatory torecognize and respond to it in RFCOMM (Although the handling of individualsettings are implementation-dependent)

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2132

TS 0710 Adaptations for RFCOMM 5 June 2003 413

BLUETOOTH SPECIFICATION Version 11 page 413 of 1084

RFCOMM with TS 0710

552 Remote Line Status Command (RLS)

This command is used for indication of remote port line status

The RLS command is specified as optional in TS 0710 but it is mandatory torecognize and respond to it in RFCOMM (Although the handling of individualsettings are implementation-dependent)

553 DLC parameter negotiation (PN)

The PN command is specified as optional in TS 0710 but it is mandatory touse for RFCOMM implementations conforming to the Bluetooth specificationversion 11 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 as described below and in Section 65 TS0710 does not explicitly disallow use at any time but after the DLC is estab-lished the responder of a PN request may refuse to change any parameters(by simply including its current parameter set in the response)

There are some parameters in the PN command which convey information notapplicable to RFCOMM These fields must therefore be set to predeterminedvalues by the sender and they must be ignored by the receiver This concernthe following fields (see table 3 in ref [1])

bull I1-I4 must be set to 0 (Meaning use UIH frames)

bull T1-T8 must be set to 0 (Meaning acknowledgment timer T1 which is notnegotiable in RFCOMM)

bull NA1-NA8 must be set to 0 (Meaning number of retransmissions N2 always0 for RFCOMM)

The CL1 -CL4 field is completely redefined (In TS0710 this defines the con-vergence layer to use which is not applicable to RFCOMM In RFCOMM inBluetooth versions up to 10B this field was forced to 0)

In the PN request sent prior to a DLC establishment this field must contain thevalue 15 (0xF) indicating support of credit based flow control in the sender

See Table 53 below If the PN response contains any other value than 14(0xE) in this field it is inferred that the peer RFCOMM entity is not supportingthe credit based flow control feature (This is only possible if the peer RFCOMM implementation is only conforming to Bluetooth version 10B) If aPN request is sent on an already open DLC then this field must contain thevalue zero it is not possible to ldquoset initial creditsrdquo more than once per DLC acti-vation

A responding implementation must set this field in the PN response to 14(0xE) if (and only if) the value in the PN request was 15

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2232

414 5 June 2003 TS 0710 Adaptations for RFCOMM

BLUETOOTH SPECIFICATION Version 11 page 414 of 1084

RFCOMM with TS 0710

The K1 - K3 field is completely redefined (In TS0710 this is the window sizefor error recovery mode which is not applicable to RFCOMM In RFCOMM inBluetooth versions up to 10B this field was forced to 0)

In the PN requestresponse this field is now interpreted as the initial amount of

credits issued to the peer Thus this field may take any value in the range from0 - 7 both in the request and in the response

This interpretation depends on the contents of the CL1 - CL4 field definedabove ie when credit based flow control is not indicated K1 - K3 must beforced to 0

If a command is received with invalid (or for some reason unacceptable) valuesin any field a DLC parameter negotiation response must be issued with valuesthat are acceptable to the responding device Or the responder may send aDM frame on the DLC indicated in the PN commandA device receiving a PNcommand must send a response The response may be a PN response or aDM frameFor a PN command with N1 value of N1c (c for command) a PN responsemust have an N1 value N1r (r for response) where N1r lt= N1cIf the receiver is not willing to establish a connection for any reason it maysend a DM frame on the DLCI indicated in the PN command

A device receiving a PN response may either accept N1r and use this value asthe maximum frame data size or chose not to establish the connection If itchoses not to establish a connection it must send a DISC or DM frame to indi-

cate this

If this connection is subsequently established neither side may send a framewith more than N1r bytes of data

In the case that no PN frames have been exchanged before the DLC establish-ment then both implementations should use the default value described inRFCOMM spec Table 52

Bluetooth version CL1 - CL4 in PN request CL1 - CL4 in PN response

lt= 10B 0x0 0x0

gt= 11 0xF 0xE

Or 0x0 if the request was sent from a 10B device with no CFC support

Table 53 CL field values for different RFCOMM versions

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2332

Flow Control 5 June 2003 415

BLUETOOTH SPECIFICATION Version 11 page 415 of 1084

RFCOMM with TS 0710

6 FLOW CONTROL

Wired ports commonly use flow control such as RTSCTS to control communi-

cations On the other hand the flow control between RFCOMM and the lower layer L2CAP depends on the service interface supported by the implementa-tion In addition RFCOMM has its own flow control mechanisms This sectiondescribes the different flow control mechanisms

61 L2CAP FLOW CONTROL IN OVERVIEW

L2CAP relies on the flow control mechanism provided by the Link Manager layer in the baseband The flow control mechanism between the L2CAP andRFCOMM layers is implementation-specific

62 WIRED SERIAL PORT FLOW CONTROL

Wired Serial ports falls into two camps ndash software flow control using characterssuch as XONXOFF and flow control using RTSCTS or DTRDSR circuitsThese methods may be used by both sides of a wired link or may be used onlyin one direction

63 GSM TS 0710 FLOW CONTROL

The GSM TS 0710 protocol provides two flow control mechanisms1 The GSM TS 0710 protocol contains flow control commands that operate

on the aggregate data flow between two RFCOMM entities ie all DLCIs areaffected The control channel commands FCon and FCoff are defined insection 5463 in ref [1]

2 The Modem Status command as defined in section 5463 in ref [1] is theflow control mechanism that operates on individual DLCI

Note that these flow control mechanisms only relate to the flow of user payloaddata in UIH frames on DLCIs other than the multiplexer control channel (DLCI

0) Also note that it is mandatory to support these GSM TS 0710-styles of flowcontrol in order to maintain backward compability with Bluetooth version 10B

When MSC commands are used2 it is only the FC bit that affects the flow onthe RFCOMM protocol level The RTR bit (along with the other V24 signals inthe MSC command) must only be treated transparently as ldquoinformationrdquo by theRFCOMM entity

See also figure 31 The V24 signals carry information between the port emula-tion entities on behalf of applications and may also be interpreted as ldquoflow con-

2 In any case MSC commands and responses must be exchanged before the data transfer

may start as stated in the ETSI standard TS 0710 Section 54637

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2432

416 5 June 2003 Flow Control

BLUETOOTH SPECIFICATION Version 11 page 416 of 1084

RFCOMM with TS 0710

trolrdquo information as described in the section on Port Emulation Entity SerialFlow Control 64 if negotiation has been done with the RPN command

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2532

Flow Control 5 June 2003 417

BLUETOOTH SPECIFICATION Version 11 page 417 of 1084

RFCOMM with TS 0710

64 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 emu-lating An application may request a particular flow control mechanism likeXONXOFF or RTSCTS and expect the port driver to handle the flow controlOn type 2 devices the port driver may need to perform flow control on the non-RFCOMM part of the communication path ie the physical RS-232 port Thisflow control is specified via the control parameters sent by the peer RFCOMMentity (usually a type 1 device) The description of flow control in this section isfor 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 mechanismand assumes that the COMM system will handle the details The port driver could then simply ignore the request and rely on RFCOMMrsquos flow control Theapplication is able to send and receive data and does not know or care that theport driver did not perform flow control using the mechanism requested How-ever in the real world some problems arise

bull The RFCOMM-based port driver is running on top of a packet-based proto-col where data may be buffered somewhere in the communication pathThus the port driver cannot perform flow control with the same precision asin the wired case

bull The application may decide to apply the flow control mechanism itself inaddition to requesting flow control from the port driver

These problems suggest that the port driver must do some additional work toperform flow control emulation properly Here are the basic rules for flow con-trol emulation

bull The port driver will not solely rely on the mechanism requested by the appli-cation but use a combination of flow control mechanisms

bull The port driver must be aware of the flow control mechanisms requested bythe application and behave like the wired case when it sees changes on the

non-data circuits (hardware flow control) or flow control characters in theincoming data (software flow control) For example if XOFF and XON char-acters would have been stripped in the wired case they must be stripped bythe RFCOMM based port driver

bull If the application sets a flow control mechanism via the port driver interfaceand then proceeds to invoke the mechanism on its own the port driver mustbehave in a manner similar to that of the wired case (eg If XOFF and XONcharacters would have been passed through to the wire in the wired casethe port driver must also pass these characters)

These basic rules are applied to emulate each of the wired flow controlschemes Note that multiple types of flow control can be set at the same timeSection 548 in ref [1] defines each flow control mechanism

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2632

418 5 June 2003 Flow Control

BLUETOOTH SPECIFICATION Version 11 page 418 of 1084

RFCOMM with TS 0710

65 CREDIT BASED FLOW CONTROL

This is a mandatory feature that did not exist in RFCOMM in Bluetooth specifi-cations 10B and earlier Therefore its use is subject to negotiation before thefirst DLC establishment (see Section 553 and Section 651) Implementationsconforming to this specification must support it and must try to use it whenconnecting to other devices

The credit based flow control feature provides flow control on a per - DLCbasis When used both devices involved in a RFCOMM session will know for each DLC how many RFCOMM frames the other device is able to acceptbefore it buffers fill up for that DLC A sending entity may send as many frameson a DLC as it has credits if the credit count reaches zero the sender muststop 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 controlis in use This mechanism operates independently for each DLC and for eachdirection It does not apply to DLCI 0 or to non-UIH frames

651 Initial DLC Negotiation

The use of credit based flow control is a session characteristic Thus it has tobe negotiated with the PN multiplexor control command (see Section 553)before the first DLC is established

After the first successful negotiation and DLC establishment all DLCs will be

flow controlled with this scheme PN negotiation at subsequent DLC establish-ments is optional but recommended since it also establishes initial creditcount values on both sides for both sides

652 DLC Operation

When credit based flow control is being used the meaning of the PF bit in thecontrol field of the RFCOMM header is redefined for UIH frames

When the PF-bit is zero in a UIH-frame the frame is structured according toFigure 51

When the PF-bit is one in a UIH-frame the frame is structure according to Fig-ure 61 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)signifiesa number of frames for which the sender now has buffer space available toreceive on the DLC (Each frame may be sized up to agreed maximum framesize) Credits are additive meaning that received credits are added to what-ever remaining credits that may be left from before In this case the length indi-cator field (as always) indicates the number of information octets in thefollowing information field however the maximum number of allowable infor-

mation octets is decreased by one to compensate for the credit field (This is tokeep the maximum L2CAP payload size constant) This means that for UIH-frames with the PF-bit = 0 the maximum size of the information field is the

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2732

Flow Control 5 June 2003 419

BLUETOOTH SPECIFICATION Version 11 page 419 of 1084

RFCOMM with TS 0710

negotiated one (= the N1 parameter) whereas for UIH-frames with the PF-bit= 1 the actual maximum size is one less (N1 - 1)

Figure 61 Frame Structure for Basic option UIH frames with PF-bit = 1 and credit based flow control used Note that the opening and closing flags from 0710 Basic option are excluded inRFCOMM

653 Other flow control aspects

When credit based flow control is being used on a session the followingapplies

bull The FCon and FCoff multiplexer control commands must not be used

bull The FC-bit in the MSC-command has no meaning it should be set to zero inMSC-commands and it should be ignored by a receiver

Flag Address Control

Length

Indicator Credits Information FCS Flag

0111

1101

1 octet 1 octet 1 or 2

octets

1 octet Unspecified length

but integral number

of octets

1 octet 0111

1101

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2832

420 5 June 2003 Interaction with Other Entities

BLUETOOTH SPECIFICATION Version 11 page 420 of 1084

RFCOMM with TS 0710

7 INTERACTION WITH OTHER ENTITIES

71 PORT EMULATION AND PORT PROXY ENTITIESThis section defines how the RFCOMM protocol should be used to emulateserial ports Figure 71 shows the two device types that the RFCOMM protocolsupports

Figure 71 The RFCOMM communication model

Type 1 devices are communication endpoints such as computers and printers

Type 2 devices are part of a communication segment eg modems

711 Port Emulation Entity

The port emulation entity maps a system specific communication interface(API) to the RFCOMM services

712 Port Proxy Entity

The port proxy entity relays data from RFCOMM to an external RS-232 inter-

face linked to a DCE The communications parameters of the RS-232 interfaceare set according to received RPN commands see Section 551

72 SERVICE REGISTRATION AND DISCOVERY

Registration of individual applications or services along with the informationneeded to reach those (ie the RFCOMM Server Channel) is the responsibilityof each application respectively (or possibly a Bluetooth configuration applica-tion acting on behalf of legacy applications not directly aware of Bluetooth)

Below is a templateexample for developing service records for a given service

or profile using RFCOMM It illustrates the inclusion of the ServiceClassListwith a single service class a ProtocolDescriptor List with two protocols

Port Emulation Entity

Baseband

L2CAP

RFCOMM

Legacy Application

Port Proxy Entity

Baseband

L2CAP

RFCOMM

DCE (eg a modem)

Cable RS-232

Type 1 Device Type 2 Device

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 2932

Interaction with Other Entities 5 June 2003 421

BLUETOOTH SPECIFICATION Version 11 page 421 of 1084

RFCOMM with TS 0710

(although there may be more protocols on top of RFCOMM) The exampleshows the use of one other universal attribute (ServiceName) For each ser-vice running on top of RFCOMM appropriate SDP-defined universal attributesandor service-specific attributes will apply For additional information on Ser-vice Records see the SDP Specification Section 22 on page 340

The attributes that a client application needs (at a minimum) to connect to aservice on top of RFCOMM are the ServiceClassIDList and the ProtocolDe-scriptorList (corresponding to the shaded rows in the table below)

Notes

1 Defined in ldquoBluetooth Assigned Numbersrdquo(httpwwwbluetoothorgassigned-numbershtm)

2 For national language support for all rsquodisplayablersquo text string attributes anoffset has to be added to the LanguageBaseAttributeIDList value for theselected language (see the SDP Specification Section 5114 on page 373 for details)

3 To be defined (where necessary) for the specific service

4 For a specific service some of the SDP-defined universal attributes mayapply See the SDP Specification Section 51 on page 366

5 This indicates the class of service It can be a single entry or a list of serviceclasses ranging from generic to most specific

Item Definition TypeSize Value Attribute ID

ServiceClassIDList Note1 0x0001

ServiceClass0 Note5 UUID32-bit Note1ProtocolDescriptorList 0x0004

Protocol0 L2CAP UUID32-bit L2CAP

Note1

Protocol1 RFCOMM UUID32-bit RFCOMM

Note1

ProtocolSpecificParameter0 Server

Channel

Uint8 N = server

channel

[other protocols] UUID32-bit Note1

[other protocol-specific parame-

ters]

Note3 Note3 Note3

ServiceName Displayable

text name

DataElement

String

rsquoExample

servicersquo

Note2

[other universal attributes as

appropriate for this service]

Note4 Note4 Note4 Note4

[service-specific attributes] Note3 Note3 Note3 Note3

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 3032

422 5 June 2003 Interaction with Other Entities

BLUETOOTH SPECIFICATION Version 11 page 422 of 1084

RFCOMM with TS 0710

73 LOWER LAYER DEPENDENCIES

731 Reliability

RFCOMM uses the services of L2CAP to establish L2CAP channels toRFCOMM entities on other devices An L2CAP channel is used for theRFCOMMTS 0710 multiplexer session On such a channel the TS 0710frames listed in Section 42 are sent with the adaptation defined inSection 51

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 remoteentity so they are acknowledged on the RFCOMM level (but not retransmittedin the absence of acknowledgment see Section 53) Data frames do not

require any response in the RFCOMM protocol and are thus unacknowledged

Therefore RFCOMM must require L2CAP to provide channels with maximumreliability to ensure that all frames are delivered in order and without dupli-cates Should an L2CAP channel fail to provide this RFCOMM expects a linkloss notification which should be handled by RFCOMM as described inSection 523

732 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 (ie usehold sniff or park see rsquoBaseband Specificationrsquo Section 10103 on page 124)This will be done without any interference from RFCOMM RFCOMM can stateits latency requirements to L2CAPThis information may be used by lower lay-ers to decide which low power mode(s) to use

The RFCOMM protocol as such does not suffer from latency delays incurred bylow power modes and consequentially this specification does not state anymaximum latency requirement on RFCOMMrsquos behalf Latency sensitivity inher-ently depends on application requirements which suggests that an RFCOMMservice interface implementation could include a way for applications to statelatency requirements to be aggregated and conveyed to L2CAP by theRFCOMM implementation (That is if such procedures make sense for a partic-ular platform)

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 3132

References 5 June 2003 423

BLUETOOTH SPECIFICATION Version 11 page 423 of 1084

RFCOMM with TS 0710

8 REFERENCES

[1] TS 0710 ver 630 ETSI

[2] Bluetooth L2CAP Specification

[3] Bluetooth SDP Specification

[4] See ldquoBluetooth Assigned Numbersrdquohttpwwwbluetoothorgassigned-numbershtm

882019 rfcomm

httpslidepdfcomreaderfullrfcomm 3232

BLUETOOTH SPECIFICATION Version 11 page 424 of 1084

RFCOMM with TS 0710

9 TERMS AND ABBREVIATIONS

The following terms are used throughout the document

DTE Data Terminal Equipment ndash in serial communications DTE refers to a

device at the endpoint of the communications path typically a com-

puter or terminal

DCE Data Circuit-Terminating Equipment ndash in serial communications DCE

refers to a device between the communication endpoints whose sole

task is to facilitate the communications process typically a modem

RFCOMM initiator The device initiating the RFCOMM session iesetting up RFCOMM

channel on L2CAP and starting RFCOMM multiplexing with the SABM

command frame on DLCI 0 (zero)

RFCOMM Client An RFCOMM client is an application that requests a connection to

another application (RFCOMM server)

RFCOMM Server An RFCOMM server is an application that awaits a connection from an

RFCOMM client on another device What happens after such a con-

nection is established is not within the scope of this definition

RFCOMM Server

Channel

This is a subfield of the TS 0710 DLCI number This abstraction is

used to allow both server and client applications to reside on both sides

of an RFCOMM session