|
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.
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).
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.)
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.
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.
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.
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.
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.
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:
- 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.
- Optionally, require authentication of the remote device to be
performed. Also optionally, require encryption to be turned on.
- Request a new L2CAP channel to the remote RFCOMM entity.
- Initiate an RFCOMM session on the L2CAP channel.
- 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:
- If requested by the remote device, take part in authentication
procedure and, upon further request, turn on encryption.
- Accept a new channel establishment indication from L2CAP.
- Accept an RFCOMM session establishment on that channel.
- 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.
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.
This section describes the requirements on RFCOMM in
units complying with the Serial Port profile.
According to TS 07.10 , section 5.4.6.3.7, 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.
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.
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.
The following text together with the associated
sub-clauses defines the mandatory requirements with regard to this
profile.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.)
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.
|
