You are on page 1of 19

10

RFCOMM

RS-232 serial ports have nine circuits, which can be used for transferring data and sig-
nalling. RFCOMM can emulate the serial cable line settings and status of an RS-232 ser-
ial port. RFCOMM provides multiple concurrent connections by relying on L2CAP to
handle multiplexing over single connections, and to provide connections to multiple de-
vices.
RFCOMM relies on the Bluetooth baseband to provide reliable in-sequence deliv-
ery of byte streams. It does not have any ability to correct errors. RFCOMM’s flow con-
trol also uses the baseband’s capabilities.
RFCOMM data rates will be limited in devices where there is a physical serial port
involved (Type 2 devices). Implementations may optionally pace data on virtual serial
ports (in Type 1 devices). In the absence of pacing, RFCOMM will deliver the highest
possible data rate, although what the highest data rate is can be a complicated issue in the
presence of multiple connections (see Chapter 18).
RFCOMM is a simple, reliable transport protocol with framing, multiplexing, and
the following additional provisions:

• Modem status—RTS/ CTS, DSR/ DTR, DCD, ring.
• Remote line status—Break, overrun, parity.
• Remote port settings—Baud rate, parity, no of data bits etc.
• Parameter negotiation (frame size).

172

Bluetooth: Connect Without Cables
By Jennifer Bray and Charles Thurman
© 2001 by Prentice Hall PTR
Prentice-Hall, Inc.
Upper Saddle River, NJ 07458

Some processors reserve a special range of addresses for I/O. A Type 1 device would usually be the end of a communication path. This allows them to reduce the load on the processor. Because UARTs look like areas of memory to a micro- processor. 10. for example. The port proxy entity relays data from RFCOMM to an external RS-232 interface linked to another device. This can be used to connect to legacy applications as shown.1 SERIAL PORTS AND UARTS Typically. Similarly. the UART transfers the bits between the cables and buffers.2 TYPES OF RFCOMM DEVICES RFCOMM supports two types of devices: • Type 1—Internal emulated serial port (or equivalent). A protocol stack for a Type 1 RFCOMM device is shown at the left of Figure 10–1. The signals from a UART are connected. and specifies how a serial data stream can be emulated.Types of RFCOMM Devices 173 10. A protocol stack for a Type 2 RFCOMM device is shown at the right of Figure 10–1. • Type 2—Intermediate device with physical serial port. a PC or printer. But because the serial stream from an RS-232 port is viewed by the microprocessor after it has been through a UART. it is possible to emulate a serial port in software by taking an area of memory and setting values as they would appear if they were set by a UART. or it can be used to connect to applications specifically written for Bluetooth. Instead of the processor having to be interrupted for every single bit that is sent down the cables. The Bluetooth RFCOMM specification talks about emulating the nine circuits of an RS-232 serial port. other systems can map them into any part of normal memory. then the processor only has to get involved when there is a whole buffer to deal with. RFCOMM connects up to the lower layers of the software stack via L2CAP. Type 2 devices are intermediate devices which sit in the middle of a communication path. . UARTs use buffers to convert between serial and parallel data. A UART connects to some piece of hardware: wires or buffers. serial port transmit and receive data lines are connected to a UART (Universal Asynchronous Receiver Transmitter). A modem is an example of a Type 2 device. The port emulation entity maps a system specific communication interface (API) to the RFCOMM services. software dealing with serial ports is actually handling parallel data. so they appear in the system address map. RFCOMM software deals with parallel data delivered by the lower layers of the Bluetooth stack. The job of the UART is to convert between the serial data sent down cables and the parallel data processing which devices use.

• UIH—Unnumbered Information with Header check. The RFCOMM frames become the data payload in L2CAP packets. • DISC—Disconnect (disconnect command).10’s features are adapted for Blue- tooth. UIH frames on DLCI = 0 are used to send control messages.10 feature frames and commands.10 frames over L2CAP using a subset of TS 07. SABM.3 RFCOMM FRAME TYPES RFCOMM is based on GSM TS 07. . • DM—Disconnected Mode (response to a command when disconnected). and DISC are “low.10. 10. which is an asymmetric protocol used by GSM cellular phones to multiplex several streams of data onto one physical serial cable. DM. UA.174 RFCOMM DCE (e. RFCOMM is symmetric. A Modem) RS-232 Cable Legacy Application Port Emulation Entity Port Proxy Entity RFCOMM RFCOMM L2CAP L2CAP Host Controller Interface Host Controller Interface Link Manager Link Manager Link Controller Link Controller Radio Radio Figure 10–1 Type 1 and Type 2 RFCOMM devices. There are five different frame types: • SABM—Start Asynchronous Balanced Mode (startup command). RFCOMM uses chan- nels. Some of TS 07. each of which has a Data Link Connection Identifier (DLCI). UIH frames on DLCIs ≠ 0 are used to send data.g. RFCOMM communicates with frames. and sends TS 07. • UA—Unnumbered Acknowledgement (response when connected).level” control frames.

it is not likely to be acknowledged a second time. and sends back an UA frame. the responder replies to the SABM frame with a UA (un- numbered acknowledgement) frame. This is different from GSM 07.10 also has optional UI (Unnumbered Information) frames. Figure 10–2 shows an RFCOMM channel setup being refused in this way. the Bluetooth baseband provides a reliable link. Set up L2CAP channel for RFCOMM Set up L2CAP connection with PSM = 0x0003 Responding RFCOMM RFCOMM SABM Frame (DLCI = 0) Initiating For first RFCOMM connection. the connection will be shut down. Any L2CAP frames received with this value in the PSM field will be sent to RFCOMM for processing. In the case of RFCOMM. Disconnect L2CAP it can’t be used for other services) Figure 10–2 Refusing an RFCOMM connection. it goes into Asynchronous Balanced Mode (ABM).10.4 CONNECTING AND DISCONNECTING Because RFCOMM frames are carried in the payload of L2CAP packets. 10. RFCOMM has a 60s timer which is started when a command is sent. it must send a DISC (disconnect) command frame on the same DLCI as the original SABM frame just in case the other side has come back into range and thinks the connection is still active. The first frame to be sent on an RFCOMM channel is a SABM frame. which resends the command when the timer elapses. This is defined in the Bluetooth core specification as 0x0003. If the connection succeeds. . This is followed by a Parameter Negotiation (PN) command from the initiator and PN response from the responder. this is a Start Asynchronous Balanced Mode command. If the responding device’s RFCOMM is willing to connect. the timeout can be extended because security procedures might mean that this command takes longer to process than others. as shown in Figure 10–4. it refuses the con- nection by sending a DM frame. If RFCOMM ever times out and disconnects.Connecting and Disconnecting 175 GSM TS 07. RFCOMM has a reserved Protocol and Service Multiplexor (PSM) value for L2CAP. RFCOMM doesn’t use these. If the responding device’s RFCOMM doesn’t want to connect. try to start multiplexor Responder refuses DM Frame (DLCI = 0) L2CAP connection is not needed (because it uses PSM = 0x0003. an L2CAP con- nection must be set up before an RFCOMM connection can be set up. Figure 10–3 shows a channel being closed down because the ini- tiator timed out. For the SABM command. If an acknowl- edgement isn’t received when the timer elapses. so if the command wasn’t acknowledged first time.

start multiplexor UA Frame (DLCI = 0) PN Command Optionally negotiate parameters for data link connection Responding PN Response RFCOMM RFCOMM Initiating SABM Frame Open data link connection. Once the UA frame has been re- ceived. modem status commands are exchanged to communicate the state of the control Set up L2CAP channel for RFCOMM Set up L2CAP connection with PSM = 0x0003 SABM Frame (DLCI = 0) For first RFCOMM connection. SABM Frame (DLCI = 0) RFCOMM RFCOMM Initiating try to start multiplexor Timeout and send DISC frame DISC Frame (DLCI = 0) L2CAP connection is not needed (because it uses PSM = 0x0003. other RFCOMM channels must be set up. To transfer data. Figure 10–4 shows a second RFCOMM channel being set up to transfer data.176 RFCOMM Set up L2CAP channel for RFCOMM Set up L2CAP connection with PSM = 0x0003 Responding For first RFCOMM connection. Disconnect L2CAP it can’t be used for other services) Figure 10–3 RFCOMM channel timeout. optionally negotiate security LMP Authenticaton & Encryption UA Frame Exchange modem status commands and responses MSC Exchange data on the connection User Data on UIH Frames Figure 10–4 Message sequence chart for establishing an RFCOMM connection. . this is available for RFCOMM signalling. so there is a pause for LMP authentication and encryption between the SABM command frame and the UA response frame. the channel re- quires authentication. In this case. Once a connection with DLCI = 0 has been set up.

or there could be an ex- change of PN command and response to configure the new connection’s parameters. When the last data link has been shut down.5. Figure 10–5 shows the frame structure for the GSM 07. and RFCOMM has to limit the number of bytes in a packet because of the limit on the size of L2CAP packets. 10. . which lacks the length field.1 Address Field An RFCOMM frame begins with an address field. To shut down an RFCOMM connection.Structure of RFCOMM Frames 177 signals. a DISC command is sent.) Figure 10–6 shows the structure of an RFCOMM frame. Then. (There is also an advanced option. 0 4 8 12 16 20 24 28 32 Flag = 10011111 Length Address Control Length or Data Data (Integral Number of Bytes) FCS Flag = 10011111 Figure 10–5 Structure of a GSM07. RFCOMM always uses the basic option.10 basic option frame except that RFCOMM misses out the start and end flags. so there is no need for flag bits to mark where the frames start and end. 10. This is identical to the GSM07. a DISC should be sent on DLCI=0 to shut down the multi- plexor. The address field is split up as shown in Fig- ure 10–7. The user data should include MSCs (Modem Status Commands). which communi- cate the state of serial port control signals. This identifies which of the many mul- tiplexed channels the frame belongs to.10 basic option frame. Data can then be transferred immediately as shown.10 standard.10 basic option.5 STRUCTURE OF RFCOMM FRAMES RFCOMM borrows its frame structure from the GSM 07. There is no need to pick RFCOMM frames out of a data stream. whichever device shut down the multiplexor is responsible for disconnect- ing the L2CAP channel. RFCOMM doesn’t need the start and end flags because each RFCOMM frame is carried in a single L2CAP packet.

The EA (Extend Address) field can be used to extend an address.10. there will never be any need to use extended addressing. the respon- der always sets the direction bit to 0 (D=0).10 applications. As long as the traffic follows this original pattern. then more address octets follow. so commands from the responder and responses from the initiator have C/R = 0. After the C/R bit comes the Data Link Connection Identifier (DLCI). Since the Bluetooth specification says that server applications are assigned a server channel number in the range 1 to 30 and an RFCOMM address frame has 5 bits for the server channel. but in RFCOMM. 0 1 2 3 4 5 6 7 8 EA=1 C/R D Server Channel Figure 10–7 Address field. In GSM TS0. but 0 and 31 are reserved. it is split up into a direction bit and a server channel number. The initiator always sets the direction bit to 1 (D=1). . but also on which end of the channel is sending the frame. If EA=0. the initiator sets C/R = 1 and the responder sets C/R = 0. Its value depends not only on whether the frame carries a command or a response.178 RFCOMM 0 4 8 12 16 20 24 28 32 Length Address Control Length or Data Data (0 . As with the C/R bits. so only 1 to 30 can be allocated as server channel numbers for ser- vices. For exchanges in the opposite di- rection. channel 31 is reserved by TS 07. Channel 0 is used for sending control information. When sending data. The C/R (Command/Response) bit says whether the frame is a command or a re- sponse. then this is the last octet of the address. who is the initiator and responder is defined by which device sent the SABM frame to start up the connection. the C/R bit is 0. so the EA bit will always be set to 1 in an RFCOMM address field.32767 Bytes) FCS Figure 10–6 Structure of an RFCOMM frame. this would give it a range from 0 to 31. The device which set up the connection (by sending a SABM command on DLCI 0) is called the initiator.10. The server channel number has 5 bits. if EA=1. so commands from the ini- tiator and responses from the responder have C/R = 1. the C/R bit is 1. this is one undivided field. Figure 10–8 illustrates how the C/R bit is set. Bluetooth avoids using channels which are reserved by TS 07.10 to preserve com- patibility with TS 07. The device which responded (by sending the UA response on DLCI 0) is called the responder.

The RFCOMM server channel number in the responding device is used for the DLCI. in responses. one device can have up to 30 services using RFCOMM.) P/F is the Poll/Final bit.Structure of RFCOMM Frames 179 SABM Frame (DLCI = 0. (These match the values used in the corresponding GSM TS 07.5. This is used to identify the type of the frame. C/R = 1) Command from initiator Command (C/R = 1) Response from responder Responding C/R = 1 RFCOMM Response (C/R = 1) RFCOMM Initiating Command from responder Command (C/R = 0) Response from initiator C/R = 0 Response (C/R = 0) Data from responder Data (C/R = 1) Data from initiator C/R set as for commands Data (C/R = 0) Figure 10–8 Settings of C/R bit in RFCOMM exchanges.10 Frames. it is called the P (Poll) bit. 10. Table 10–1 shows the control field values used in RF- COMM frames. In commands.2 Control Field Referring back to Figure 10–6. Table 10–1 Control Field Values Control Bit Number 1 2 3 4 5 6 7 8 SABM (Set Asynchronous 1 1 1 1 P/F 1 0 0 Balanced Mode) UA (Unnumbered Acknowledgement) 1 1 0 0 P/F 1 1 0 DM (Disconnect Mode) 1 1 1 1 P/F 0 0 0 DISC (Disconnect) 1 1 0 0 P/F 0 1 1 UIH (Unnumbered Information with 1 1 1 1 P/F 1 1 1 Header Check) . the next field in an RFCOMM frame is the control field. Because server channel numbers 1 to 30 are available. C/R = 1) For first RFCOMM connection. The DLCI is calculated once before the data link connection is established. initiator starts multiplexor C/R = 1 UA Frame (DLCI = 0. it is called the F (Final) bit.

it is calculated on the address and control fields. the size of RFCOMM data will also be restricted. 0 2 4 6 8 10 12 14 16 EA 7 bits of Length Field =1 EA 15 bits of Length Field =0 Figure 10–9 Structure of RFCOMM length fields. 10. The responding device should send back its responses with the F bit set to 1. the frame check sequence is calculated on the address control and length fields. so the length field is one byte long. If the EA bit is 0.4 Data The data field is only present in UIH frames.3 Length Field The length field begins with an EA bit as shown in Figure 10–9. 10. the number of bits the FCS will be calculated on. The default length of an RFCOMM frame is 32 bytes. then it is followed by 15 bits of length. the maximum length is 32767. 10. (c) Add the results of (a) and (b) modulo 2.5 Frame Check Sequence To calculate the FCS: Count up k. UA.180 RFCOMM A command with its P bit set to 1 is used when a response or a series of responses is wanted from the device at the far end of the link. Then: (a) Calculate the remainder of xk ( x7 + x6 x5 + x4 + x3 + x2 + x1 + 1) divided modulo 2 by the generator polynomial ( x8 + x2 + x + 1).5. so the length field is two bytes long. . DISC. (b) Take the contents of the frame that the FCS is calculated over before any start and stop elements have been inserted. then it is fol- lowed by 7 bits of length. For UIH frames. so if a system has a smaller L2CAP MTU. but SABM or DISC commands and UA responses are thrown away if the P/F bit is set to zero. and before any other extra bits have been in- serted. There should only ever be one command frame with P bit set to 1 waiting for a response. For SABM. The size limit is set by the Maximum Transmission Unit (MTU) on L2CAP packets. DM packets are processed regardless of the state of the P/F bit. If this is 1.5. Multiply by x8 and divide by the generator polynomial ( x8 + x2 + x + 1). and DM frames. and take the 1’s complement to get the FCS.5. There must be an integral number of bytes in the data up to 32767.

They are used to control the RFCOMM link. This pre-calculation could be done when the channel is set up.6. • Test—Checks communication link. • MSC—Modem status. This might be a drawback for reliable data transmission. • FCon / FCoff—Aggregate flow control on all connections. It is possible to send several multi- plexor command messages in one RFCOMM frame.1 PN—DLC Parameter Negotiation The PN command is used to negotiate the parameters of a data link connection. 10. A PN command is identified by the type field shown in Figure 10–11. default parameters will be used for the connection. or to split a multiplexor command message over more than one frame. If no PN commands are sent. The multiplexor commands and responses are carried as messages inside an RFCOMM UIH frame as shown in Figure 10–10. There are seven types of commands or responses: • PN—DLC parameter negotiation. • RPN—Remote Port Negotiation. although this is not com- pulsory. 10.6 MULTIPLEXOR FRAMES Multiplexor commands and responses are sent on DLCI = 0. PN com- mands are exchanged before a new data link connection is opened. . • NSC—Non-Supported Command (response only). This type field is the first information byte in the UIH frame carrying the PN command (see Figure DLCI = 0 Control = UIH Length Information FCS Type Length Value 1 Value 2 … Value N Figure 10–10 Structure of an RFCOMM multiplexor control frame.Multiplexor Frames 181 Because UIH frames only calculate FCS on the address and control fields. their data field is not protected by the FCS. but it does have the advantage that the FCS patterns can be pre-calculated for all the DLCIs that are in use. used for flow control per connection. • RLS—Remote Line Status.

The C/R bit is used to indicate whether the message is a command or a response. In RF- COMM UIH frames indicated by the value 0b1000 are used. The length field in a PN message is always set to 8. 10–11). • Four I bits give the type of frames used to carry information on the channel. These bytes define the parameters which will be used on a data link connection as follows: • Six DLCI bits identify the data link connection for which parameters are being ne- gotiated. 0 1 2 3 4 5 6 7 8 DLCI 0b00 I (Type of Frame for Information) CL (Convergence Layer to Use) = 0b1000 for UIH Frames =0b0000 P (priority) 0b00 T (Value of Acknowledgement Timer) 60-second Timer = 0b00000000 N (Maximum Frame Size . and the value field contains 8 bytes as shown in Figure 10–12. • Two padding bits which are always set to zero follow the DLCI. these are inserted to avoid splitting parameters across bytes. .16 bits) NA (Maximum Number of Retransmissions) = 0b00000000 K (Error Recovery Window) 0b00000 =0b000 Figure 10–12 Content of value bytes in a PN message. The EA bit is 1 because the type field occupies one byte.182 RFCOMM 0 1 2 3 4 5 6 7 8 EA=1 C/R Type = 000001 Figure 10–11 Type field for Parameter Negotiation (PN).

This field is set to 0 to indicate that the timer is not negotiable. • Three K bits define the window size for error recovery mode. Once it has a satis- factory set of parameters in the reply. • Eight NA bits give the maximum number of retransmissions. Because the Bluetooth baseband gives RFCOMM a reliable transport layer. in GSM 07. • Six P bits assign a priority to the data link connection: 0 is the lowest priority. but the device at the other end of the connection will use the value it sent in its message. so these bits are not interpreted by RFCOMM. it can go on to set up the connection. It is worth noting that RFCOMM follows the conventions of the GSM 07. The response may not change the DLCI. support of the PN message and its response are compulsory. this would be used to trigger a retransmit.Multiplexor Frames 183 • Four CL bits give the convergence layer to used. and the other responds with another PN message. if the timer elapses. • Two padding bits which are always set to zero follow the P bits. the device which sent the first PN messages will still use the timer it proposed. although if default parameters are satisfactory. The timer’s value is not negotiable. RFCOMM will not retransmit. these are inserted to avoid splitting parameters across bytes. so this value is set to zero.10. . in RFCOMM. The response may send back a different timer value.10 stan- dard and numbers the bits in a frame from 1 for the least-significant bit to 8 for the most significant bit. • Sixteen N bits give the maximum size of the frame. In GSM 07. RFCOMM uses Type 1 (unstruc- tured octet stream) = 0b0000 in versions after 1. PN mes- sages do not have to be sent. • Eight T bits give the value of the acknowledgement timer. • Five padding bits set to zero fill the rest of the last value field to round up the values to an integral number of bytes. PN messages may be exchanged until the device which sent the first message is happy with the parameters it gets sent back to it. 63 is the highest. PN messages are optional.10. In RFCOMM. but is fixed at 60s. the convergence layer. This may be confusing to people who are used to seeing the bits in a byte numbered from 0 to 7. All parameters being negotiated are sent with the LSB in bit 1. In this case. or the timer value. The response may have a smaller value for the maximum frame size.0b this may also be set to 0x0F to enable credit based flow control. One device sends a PN message. the con- nection is closed down. the priority. this is the general rule for RFCOMM information. RFCOMM uses basic mode. but it may not propose a larger value for this parameter.

the EA bit is set to 1. it sends another MSC with the flow control bit set to 0. . The structure of the type field for the two flow control commands is shown in Fig- ure 10–14. Both begin with an EA bit. This is the Modem Status Command (MSC). • RTC—Ready To Communicate bit. 10. • FC—Flow Control bit. When the device is able to receive again. The type field for the test command is shown in Figure 10–13. 10. the length byte gives the number of value bytes which follow. The length field in the frame carrying the command is set to zero be- cause there is no other data in the frame. which is 1 to indicate that there is only one byte in the command type. The command field of the MSC contains virtual V. it sends a Flow Control on (FCon) command. and is used to hold a test pattern. 10. The number of value bytes is not fixed.184 RFCOMM 0 1 2 3 4 5 6 7 8 EA=1 C/R Type = 0b000100 Figure 10–13 Type field for test.6.2 Test The test command is used to check the RFCOMM connection.6. that is to say the settings that the RS-232 control wires would have if the RFCOMM data were being transferred across wires rather than across a Bluetooth connection. The C/R bit is used to indicate whether the message is a command or a response.3 FCon / FCoff—Aggregate Flow Control on All Connections RFCOMM has a flow control mechanism which applies to all channels between two RFCOMM entities. The C/R bit is used to indicate whether the message is a command or a response. The EA bit is 1 because the type field occupies one byte. When either RFCOMM entity can’t receive RFCOMM information. The C/R bit is used to indicate whether the mes- sage is a command or a response. it sends a Flow Control off (FCoff) command.4 MSC—Modem Status Command RFCOMM also has a flow control mechanism which can be applied to just one channel at a time. The signals in the command field are as follows: • EA—Extended Address.24 control signals. When it is able to receive data again. set to 1 when the device is ready to communi- cate. Because only a sin- gle byte is used. As is normal. The remote end of the link echoes the same value bytes back. set to 1 to indicate there is only 1 byte of command. and it is indicated by the type field shown in Figure 10–15. set to 1 when a device is unable to accept any RFCOMM frames.6.

The response just carries a copy of the signals from the command. A signal to say that valid data is being sent can be used to activate circuits to handle the data. 1 indicates an incoming call. It might be obvious when a packet is sent that it is going to have valid data. • DV maps onto DCD (Data Carrier Detect). In the MSC. It should also be sent whenever the signals need to be changed. who would bother to send a packet with invalid data? However. • RTR maps onto RTS (Request To Send) and CTS (Clear To Send). • DV—Data Valid.Multiplexor Frames 185 0 1 2 3 4 5 6 7 8 EA=1 C/R FC On = 0b000101 EA=1 C/R FC Off = 0b000110 Figure 10–14 Type fields for FCon and FCoff commands. These values may not seem to make sense when sent in a packet. such signals make more sense. • RTR—Ready To Receive bit. set to 0 when the device cannot receive data and 1 when it can receive data. • IC maps onto RI (Ring Indication). Figure 10–16 shows how the signals are carried in the control field of the command. the state of the signals in the device sending the command is sent. when dealing with physical serial port lines. The signals from an MSC map onto RS-232 signals as follows: • RTC maps onto DSR (Data Set Ready) and DTR (Data Terminal Ready). set to 1 to indicate that valid data is being sent.24 signals. The MSC is sent on a connection before any data is sent to establish the state of the RS-232 control signals. The MSC command just mimics the values of the V. . but that is because they map onto the lines of an RS-232 interface. 0 1 2 3 4 5 6 7 8 EA=1 C/R Type = 0b000111 Figure 10–15 Type field for MSC command. • IC—Incoming Call. which would be used on a wired RS-232 -interface.

If any of the communication settings need to be changed during a connection. Figure 10–18 shows the order of values within an RPN command with length byte set to 8. If the length byte is set to 8. The RPN type field is shown in Figure 10–17. a parameter mask bit set to 1 means the new value has been accepted. Conversely. . In this case. then there is a single value byte which contains the DLCI for the connection. then it means the proposal sent in an RLS has not been accepted. and the sender of the response is now using the new value. the remote end replies with the current parameters on the link. if a parameter mask bit is set to 1. In an RPN response.186 RFCOMM 0 1 2 3 4 5 6 7 8 EA=1 FC RTC RTR Reserved IC DV Figure 10–16 MSC control signal field. 10. then eight bytes of link para- meters follow. and the message is inter- preted as a request for the link’s parameters. then the parameter is not being changed and the value can be ignored. If the length is 1. If it is set to 0. If they are sent in a command. In an RPN command. The values of the various fields in an RLS command have the same meanings as in GSM 07.6. it indicates a particular pa- rameter that should be changed. The parameter mask defines which parameters are being changed by the message. The EA bit is 1 because the type field occupies one byte. The length byte in an RPN command is either 1 or 8. the RPN command can be resent to change them. The C/R bit is used to in- dicate whether the message is a command or a response.10. then they are a request to set up the link’s parameters.5 RPN—Remote Port Negotiation The Remote Port Negotiation (RPN) command is used to set communication settings at the remote end of a data link connection. Figure 10–19 shows the position of bits in the RPN parameter mask. 0 1 2 3 4 5 6 7 8 EA=1 C/R Type = 0b001001 Figure 10–17 Type field for RPN. if a parameter mask bit is set to 0.

. 0 1 2 3 4 5 6 7 8 Bit Data Stop Parity XON XOFF Reserved Parity Rate Bits Bits Type Char Char = 0b0 Input Output Input Output Input Output XON/ XON/ Reserved = 0b00 RTR RTR RTC RTC XOFF XOFF Figure 10–19 Bits in an RPN parameter mask. 0 1 2 3 4 5 6 7 8 EA=1 C/R Type = 0b001010 Figure 10–20 Type field for RLS.Multiplexor Frames 187 0 1 2 3 4 5 6 7 8 EA 1 DLCI Baud Rate Data Bits Stop Bits Parity Parity Type Reserved Flow Control Reserved XON XOFF Parameter Mask Figure 10–18 Value bytes in a RPN command.

then the RLS command is simply reporting that there are no errors on the line. the second value byte carries the error status in its first four bytes as shown in Figure 10–21. 0 1 2 3 4 5 6 7 8 EA =1 C/R Type = 0b001000 Figure 10–22 Type field for NSC response. a received character has overwritten a character which had not yet been read. The C/R bit is used to indicate whether the message is a command or a response. The Line (L) status bits can signal three different errors as follows: • 0b1100—Overrun error. The EA bit is 1 because the type field occupies one byte. • 0b1001—Framing error. RFCOMM implementations must recognise and respond to RLS commands. the parity was wrong on a received character. but how they deal with the line status information is up to the implementor to decide.6 RLS—Remote Line Status A device sends a Remote Line Status (RLS) command when it needs to tell the other end of the link about an error. • 0b1010—Parity error. a character did not end with a stop bit. When an RLS command is received. The RLS command is identified by the type field shown in Figure 10–20. The length byte is set to 2. as there are two value bytes: the first value byte carries an EA bit C/R bit and the data link connection identifier common to all multiplexor com- mand messages.188 RFCOMM 0 1 2 3 4 5 6 7 8 Line Status Reserved = 0b0000 Figure 10–21 Second value byte of RLS message. .6. If the first line status bit is set to 0. 10. a response is sent back with the line status copied from the command into the response.

7 NSC—Non-Supported Command (Response Only) The Non-Supported Command (NSC) Response is sent whenever a device receives a command it does not support.7 SERVICE RECORDS Bluetooth devices offering services supported by RFCOMM must have an entry in their service discovery database which gives information on how to connect over RFCOMM. RFCOMM server channel numbers are dynamic.6. Table 10–2 shows a minimal service record which might be used to provide the in- formation needed to connect to a service across RFCOMM. 10. it can be re-allocated when the service is not in use. The EA bit is 1 because the type field occupies one byte. If the message comes from the device which initi- ated the connection by sending a SABM. The type field used to identify a message containing an NSC is shown in Fig- ure 10–22. The minimum information needed to connect to a service over RFCOMM is a ser- vice name (to identify the type of service) and a channel number on which to transfer data.Summary 189 Table 10–2 Service Attributes Needed to Connect to an RFCOMM Service Item Type Value Attribute ID ServicerRecordHandle Uint32 Assigned by Server 0x0000 ServiceClassIDList 0x0001 ServiceClass0 UUID SERVICE NAME Service UUID ProtocolDescriptorList 0x0004 Protocol0 UUID L2CAP 0x0100 Protocol1 UUID RFCOMM 0x0003 ProtocolSpecificParameter0 Uint8 Server Channel # ServiceName String “TEXT NAME” 0x0000 +Language Offset 10. Since RFCOMM rests on L2CAP. The ServiceClassIDList gives the name of the service. By querying SDP records. Many services will have other additional parameters which are also needed to con- nect to the service. then C/R = 1. then C/R = 0. The ProtocolDescriptorList gives the supported protocols. That is to say a service’s channel number can change. the L2CAP service must be present whenever RFCOMM . The C/R bit is used to indicate the message is a response. If the message comes from the de- vice which responded to the initial SABM. Although a service’s channel number doesn’t change while the ser- vice is in use. a device can find out all the information it needs to connect to a service via RFCOMM.

The headset application also uses RFCOMM services to set up and control headset connections. 10. an L2CAP connection must first be set up. which shows how RFCOMM information is presented for a headset application.190 RFCOMM is present. Up to 30 data channels can be set up. see Chapter 11. which can be used to connect to legacy appli- cations. . After this is set up. Table 11–1. (In prac- tice. This service also has a text name which can be used to represent it on a user interface. Once the L2CAP con- nection is set up. RFCOMM control frames are sent back and forth to establish a sig- nalling channel with a Data Link Connection Identifier (DLCI) set to 0.8 SUMMARY RFCOMM provides serial port emulation. To set up an RFCOMM connection. RFCOMM frames are sent in the payload field of L2CAP packets. so RFCOMM can theoretically support 30 different services at once. and is also used for data transfer in several of the Bluetooth profiles. For more information. most bluetooth devices will not have the resources to support 30 different services.) RFCOMM is based on the GSM 07.10 standard with a few minor differences to allow for the differences between a Bluetooth connection and a GSM cellular phone con- nection. subsequent channels are established for transferring data. RFCOMM supports two types of devices: A Type 1 device is the end of a commu- nications path and supports an application on top of RFCOMM. and a Type 2 device is an intermediate device and has a physical RS-232 serial port on top of RFCOMM.