| |
This profile defines the requirements for Bluetooth devices necessary for the support of
the intercom functionality within the 3-in-1 phone use case. The requirements are
expressed in terms of end-user services, and by defining the features and procedures that
are required for interoperability between Bluetooth devices in the 3-in-1 phone use case.
More popularly, this is often referred to as
the ‘walkie-talkie’ usage of
Bluetooth.
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 K4 Specification from the
SIG website, or visit the Documents Page.
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.
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.
|
