SLI Practical Group B Tail-Wag
AbiWord Document

Overview of the PPP and RFCOMM Protocols and their Use in Bluetooth

The Bluetooth Stack
Benjamin Hanney's L2CAP Pages Morten Bek's LMP and HCI Pages Mark Scott's SDP Pages Paul New's TCP Pages Paul New's IP Pages James Montgomerie's PPP and RFCOMM Pages The Bluetooth Stack
[click to go to the relevant sites]

The PPP (Point-to-Point Protocol) and RFCOMM (not an acronym) protocols reside in the middle of the upper section of the Bluetooth stack.  RFCOMM provides emulation of RS232-like serial ports over the L2CAP protocol.  The connections may be multiplexed, allowing up to 59 serial channels between any two Bluetooth devices.  PPP is used to provide a method to transport datagrams over this emulated serial link, in exactly the same manner as it is used more traditionally by personal computers to provide a point-to-point datagram transmission link when connecting to another computer by modem.  In Bluetooth, as is common in other applications, the PPP link is used by the Internet Protocol to provide IP services to upper layers, such as TCP and UDP.  The possibility for use by other protocols, not directly specified in the Bluetooth standard, also exists.

RFCOMM is described in Part F:1 of the Bluetooth standard.  It is a subset of the ETSI TS 07.10 standard, as used in the GSM (Global System for Mobile Communications) standard - used by digital mobile telephones in the UK, and much of the rest of the world.

PPP is specified in Internet RFC (Request For Comments) 1661.  The standard is used in its entirety, and not modified for Bluetooth use.

These protocols must be implemented in order to comply with the Bluetooth standard, but it could be argued that their use is inefficient, both in processor time and bandwidth used for protocol headers.  They implement a datagram carrying layer by running a datagram carrying protocol (PPP) over an emulation of a serial link (RFCOMM), itself running over a datagram carrying Protocol (L2CAP).  There are moves in the Bluetooth community to allow elimination of these two layers from the stack, running IP directly over the L2CAP layer (see here and here for examples of thoughts driving the process).  Indeed, a number of third-party vendors (for example, Digianswer A/S) are beginning to offer their own IP-over-L2CAP implementations in their Bluetooth products.

The Bluetooth Special Interest Group is working on an Ethernet profile which will describe TCP/IP over Bluetooth at a lower level, and there is speculation that one of these solutions will make its way into Bluetooth 2.