Radio Baseband LMP HCI L2CAP RFCOMM SDP Profiles

K5 - Serial Port Profile


     The Serial Port Profile defines the requirements for Bluetooth devices necessary for setting up emulated serial cable connections using RFCOMM between two peer devices. The requirements are expressed in terms of services provided to applications, and by defining the features and procedures that are required for interoperability between Bluetooth devices.

    Essentially, the Serial Port Profile defines the protocols and procedures that shall be used by devices using Bluetooth for RS232 (or similar) serial cable emulation.The scenario covered by this profile deals with legacy applications using Bluetooth as a cable replacement, through a virtual serial port abstraction (which in itself is operating system-dependent).

For more details : Download the K5 Specification from the SIG website, or visit the Documents Page.

        Table Of Contents

5.1 Profile Overview
5.1.1 Scope
5.1.2 Protocol Stack
5.1.3 Roles/Configurations
5.1.4 Profile Scenarios
5.1.5 Profile Fundamentals
5.1.6 Conformance
5.2 Application Layer
5.2.1 Procedure Overview
5.2.2 Power Mode & Link Loss Handling
5.3 RFCOMM Interoperability Requirements
5.3.1 RS232 Control Signals
5.3.2 Remote Line Status Indication
5.3.3 Remote Port Negotiation
5.4 L2CAP Interoperability Requirements
5.4.1 Channel Types
5.4.2 Signalling
5.4.3 Configuration Options
5.5 SDP Interoperability Requirements
5.6 Link Manager Interoperability Requirements
5.6.1 LM Configuration Options
5.6.2 LM Error Behaviour
5.6.3 Link Policy
5.7 Link Controller Interoperability Requirements
5.7.1 Inquiry
5.7.2 Inquiry Scan
5.7.3 Paging
5.7.4 Error Behaviour


5.1  Profile Overview

5.1.1   Scope

    This profile defines how PPP networking is supported in the following situations.

  • LAN Access for a single Bluetooth device.
  • LAN Access for multiple Bluetooth devices.
  • PC to PC (using PPP networking over serial cable emulation).

5.1.2   Protocol Stack

    The Baseband , LMP  and L2CAP  are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM  is the Bluetooth adaptation of GSM TS 07.10 , providing a transport protocol for serial port emulation. SDP is the Bluetooth Service Discovery Protocol .

    The port emulation layer  is the entity emulating the serial port, or providing an API to applications. The applications on both sides are typically legacy applications, able and wanting to communicate over a serial cable (which in this case is emulated). But legacy applications cannot know about Bluetooth procedures for setting up emulated serial cables, which is why they need help from some sort of Bluetooth-aware helper application on both sides. (These issues are not explicitly addressed in this profile; the major concern here is for Bluetooth interoperability.)

5.1.3  Roles/Configurations

The following roles are defined for this profile:

  • Device A (DevA) – This is the device that takes initiative to form a connection to another device (DevA is the Initiator according to 'Configurations/Roles' in GAP).
  • Device B (DevB) – This is the device that waits for another device to take initiative to connect. (DevB is the Acceptor according to  'Configurations/Roles' in GAP ). Note that the order of connection (from DevA to DevB) does not necessarily have to have anything to do with the order in which the legacy applications are started on each side respectively.

5.1.4  Profile Scenarios

    The scenario covered by this profile is the following:

  • Setting up virtual serial ports (or equivalent) on two devices (e.g. PCs) and connecting these with Bluetooth, to emulate a serial cable between the two devices. Any legacy application may be run on either device, using the virtual serial port as if there were a real serial cable connecting the two devices (with RS232 control signalling).

    This profile requires support for one-slot packets only. This means that this profile ensures that data rates up to 128 Kbps can be used. Support for higher rates is optional.

    Only one connection at a time is dealt with in this profile. Consequently, only point-to-point configurations are considered. However, this should not be construed as imposing any limitation on concurrence; multiple executions of this profile should be able to run concurrently in the same device. This also includes taking on the two different roles (as DevA and DevB) concurrently.

5.1.5  Profile Fundamentals

    For the execution of this profile, use of security features such as authorisation, authentication and encryption is optional. Support for authentication and encryption is mandatory, such that the device can take part in the corresponding procedures if requested from a peer device. If use of security features is desired, the two devices are paired during the connection establishment phase (if not earlier).

  • Bonding is not explicitly used in this profile, and thus, support for bonding is optional.
  • Link establishment is initiated by DevA. Service discovery procedures have to be performed to set up an emulated serial cable connection.
  • There are no fixed master slave roles.
  • RFCOMM is used to transport the user data, modem control signals and configuration commands.

5.1.6  Conformance

    When conformance to this profile is claimed, all capabilities indicated mandatory for this profile shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities and optional and conditional capabilities, for which support is indicated, are subject to verification as part of the Bluetooth certification program.


5.2  Application Layer

    This section describes the feature requirements on units complying with the Serial Port profile. This profile is built upon the Generic Access Profile (GAP) .

  • When reading the GAP, the A-party (the connection initiator) is equivalent to DevA and the B-party is equivalent to the DevB.
  • All the mandatory requirements defined in GAP are mandatory for this profile.
  • Unless otherwise stated below, all the optional requirements defined in GAP are optional for this profile.

5.2.1  Procedure Overview

    Establish Link and Set up Virtual Serial Connection: This procedure refers to performing the steps necessary to establish a connection to an emulated serial port (or equivalent) in a remote device. The steps in this procedure are:

  1. Submit a query using SDP to find out the RFCOMM Server channel number of the desired application in the remote device.This might include a browsing capability to let the user select among available ports (or services) in the peer device. Or, if it is known exactly which service to contact, it is sufficient look up the necessary parameters using the Service Class ID associated with the desired service.
  2. Optionally, require authentication of the remote device to be performed. Also optionally, require encryption to be turned on.
  3. Request a new L2CAP channel to the remote RFCOMM entity.
  4. Initiate an RFCOMM session on the L2CAP channel.
  5. Start a new data link connection on the RFCOMM session, using the aforementioned server channel number.

    After step 5, the virtual serial cable connection is ready to be used for communication between applications on both sides.


    Accept link and establish virtual serial connection: This procedure refers to taking part in the following steps:

  1. If requested by the remote device, take part in authentication procedure and, upon further request, turn on encryption.
  2. Accept a new channel establishment indication from L2CAP.
  3. Accept an RFCOMM session establishment on that channel.
  4. Accept a new data link connection on the RFCOMM session. This may trigger a local request to authenticate the remote device and turn on encryption, if the user has required that for the emulated serial port being connected to (and authentication/encryption procedures have not already been carried out ).

    Register Service record in local SDP database:  This procedure refers to registration of a service record for an emulated serial port (or equivalent) in the SDP database. This implies the existence of a Service Database, and the ability to respond to SDP queries.

    All services/applications reachable through RFCOMM need to provide an SDP service record that includes the parameters necessary to reach the corresponding service/application, see Section 6.1. In order to support legacy applications running on virtual serial ports, the service registration must be done by some helper-application, which is aiding the user in setting up the port.

5.2.1  Power Mode & Link Loss Handling

    Since the power requirements may be quite different for units active in the Serial Port profile, it is not required to use any of the power-saving modes. However, requests to use a low-power mode shall, if possible, not be denied.

    If sniff, park, or hold mode is used, neither RFCOMM DLCs nor the L2CAP channel are released.

    If a unit detects the loss of link, RFCOMM shall be considered having been shut down. Before communication on higher layers can be resumed, the Initialise RFCOMM session procedure has to be performed.


5.3  RFCOMM Interoperability Requirements

    This section describes the requirements on RFCOMM in units complying with the Serial Port profile.

5.3.1  RS232 Control Signals

    According to TS 07.10 , section, all devices are required to send information on all changes in RS232 control signals with the Modem Status Command.

    However, since RFCOMM can be used with an adaptation layer implementing any kind of API (not only virtual serial ports), it is optional to use all RS232 control signals except flow control (the RTR signal in TS 07.10 [5]). This signal can be mapped on RTS/CTS or XON/XOFF or other API mechanisms, which is an implementation issue.

5.3.2  Remote Line Status Indication

    It is required to inform the other device of any changes in RS232 line status with the Remote Line Status indication command, if the local device relays information from a physical serial port (or equivalent) where overrun-, parity- or framing-errors may occur.

5.3.3  Remote Port Negotiation

    DevA may inform DevB of RS232 port settings with the Remote Port Negotiation Command, directly before DLC establishment.There is a requirement to do so if the API to the RFCOMM adaptation layer exposes those settings (e.g. baud rate, parity). DevB is allowed to send the Remote Port Negotiation command.


5.4  L2CAP Interoperability Requirements

    The following text together with the associated sub-clauses defines the mandatory requirements with regard to this profile.

5.4.1  Channel Types

    In this profile, only connection-oriented channels shall be used. This implies that broadcasts will not be used in this profile.

    In the PSM field of the Connection Request packet, the value for RFCOMM defined in the Assigned Numbers document must be used.

5.4.2  Signalling

    Only DevA may issue an L2CAP Connection Request within the execution of this profile. Other than that, the Serial Port Profile does not impose any additional restrictions or requirements on L2CAP signalling.

5.4.3  Configuration Options

    Maximum Transmission unit : This profile does not impose any restrictions on MTU sizes over the restrictions stated in the L2CAP spec (in section 6.1).

    Flush Timeout : Serial Port data is carried over a reliable L2CAP channel. The flush timeout value shall be set to its default value 0xffff.

    Quality of Service: Negotiation of Quality of Service is optional in this profile.


5.5  SDP Interoperability Requirements

    There are no SDP Service Records related to the Serial Port Profile in DevA.

    To retrieve the service records in support of this profile, the SDP client entity in DevA connects and interacts with the SDP server entity in DevB via the SDP and L2CAP procedures presented in sections 'Service Discovery' and 'L2CAP' of SDAP . In accordance to SDAP, DevA plays the role of the LocDev, while DevB plays the role of the RemDev.

5.6  Link Manager Interoperability Requirements

5.6.1  LM Configuration Options

    In addition to the requirements on supported procedures stated in the Link Manager specification itself , this profile also requires support for Encryption both in DevA and DevB.

5.6.2  LM Error Behaviour

    If a unit tries to use a mandatory feature, and the other unit replies that it is not supported, the initiating unit shall send an LMP_detach with detach reason "unsupported LMP feature."

    A unit shall always be able to handle the rejection of the request for an optional feature.

5.6.2  Link Policy

    There are no fixed master-slave roles for the execution of this profile.

    This profile does not state any requirements on which low-power modes to use, or when to use them. That is up to the Link Manager of each device to decide and request as seen appropriate, within the limitations of the latency requirement.


5.7  Link Controller Interoperability Requirements

5.7.1  Inquiry

    When inquiry is invoked in DevA, it shall use the General Inquiry procedure, see in the 'Discoverability Modes' in the GAP profile. Only DevA may inquire within the execution of this profile.

5.7.2  Inquiry Scan

    For inquiry scan, (at least) the GIAC shall be used, according to one of the discoverable modes defines in GAP. That is, it is allowed to only use the Limited discoverable mode, if appropriate for the application(s) residing in DevB.

    In the DevB INQUIRY RESPONSE messages, the Class of Device field will not contain any hint as to whether DevB is engaged in the execution of the Serial Port Profile or not. (This is due to the fact the generalised Serial Port service for legacy applications delivered by this profile does not fit within any of the major Service Class bits in the Class Of Device field definition.)

5.7.3  Paging

    Only DevA may page within the execution of this profile. The paging step will be skipped in DevA when execution of this profile begins when there already is a baseband connection between DevA and DevB. (In such a case the connection may have been set up as a result of previous paging by DevB.)

5.7.4  Error Behaviour

    Since most features on the LC level have to be activated by LMP procedures, errors will mostly be caught at that layer. However, there are some LC procedures that are independent of the LMP layer, e.g. inquiry or paging. Misuse of such features is difficult or sometimes impossible to detect. There is no mechanism defined to detect or prevent such improper use.


Note , the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.