|
The LAN Access Profile for Bluetooth devices consists
of 2 parts. Firstly, this profile defines how Bluetooth-enabled devices can
access the services of a LAN using PPP. Secondly, this profile shows how the
same PPP mechanisms are used to form a network consisting of two
Bluetooth-enabled devices.
Basically this profile defines LAN Access using PPP
over RFCOMM. (There may be other means of LAN Access in the future).
For more details : Download the K9
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).
PPP is the IETF Point-to-Point Protocol. PPP-Networking is
the means of taking IP packets to/from the PPP layer and placing them onto
the LAN. This mechanism is not defined by this profile but is a
well-understood feature of Remote Access Server products.
The Baseband , LMP and L2CAP are the OSI layer 1
and 2 Bluetooth protocols. RFCOMM is the Bluetooth adaptation of GSM TS
07.10. SDP is the Bluetooth Service Discovery Protocol.ME is the Management
Entity which co-ordinates procedures during initialization, configuration and
connection management.
Two roles are defined for bluetooth devices in this
profile, LAN Access Point (LAP)
and Data Terminal (DT):
- LAN Access Point (LAP) – This is the Bluetooth device that
provides access to a LAN (e.g. Ethernet, Token Ring, Fiber Channel, Cable
Modem, Firewire, USB, Home
Networking). The LAP provides the services of a PPP Server. The PPP
connection is carried over RFCOMM. RFCOMM is used to transport the PPP
packets and it can also be used for flow control of the PPP data stream.
- Data Terminal (DT) - This is the device that uses the services of
the LAP. Typical devices acting as data terminals are laptops,
notebooks, desktop PCs and PDAs. The DT is a PPP client. It forms a PPP
connection with a LAP in order to gain access to a LAN.
This profile assumes that the LAP and the DT each have
a single Bluetooth radio unit.
Three scenarios are covered by this profile, :
- LAN Access by a Single PC: In this scenario a single DT uses a
LAP as a wireless means for connecting to a Local Area Network (LAN). Once
connected, the DT will operate as if it were connected to the LAN via
dial-up networking. The DT can access all of the services provided by the
LAN.
- LAN Access by Multiple DTs: Here, multiple DTs use a LAP as a
wireless means for connecting to a Local Area Network (LAN). Once
connected, the DTs will operate as if they were connected to the LAN via
dial-up networking. The DTs can access all of the services provided by the
LAN. The DTs can also communicate with each other via the LAP.
- PC to PC Connection:. This is where two Bluetooth devices can
form a single connection with each other. This scenario is similar to a
direct cable connection commonly used to connect two PCs. In this scenario,
one of the devices will take the role of a LAP, the other will be a DT.
The following is a brief summary of the interactions
between a DT and a LAP. Subsequent sections in the profile provide more
detail for each of the following steps.
1: The first step is to find a LAP that is within radio
range and is providing a PPP/RFCOMM/L2CAP service. For example, the DT user
could use some application to find and select a suitable LAP.
2: If there is no existing baseband physical link, then the
DT requests a baseband physical link with the selected LAP. At some point
after the physical link establishment, the devices perform mutual
authentication. Each device insists that encryption is used on the link.
3: The DT establishes a PPP/RFCOMM/L2CAP
connection.
4: Optionally, the LAP may use some appropriate PPP
authentication mechanism. For example, the LAP may challenge the DT’s user
to authenticate himself or herself; the DT must then supply a username and
password. If these mechanisms are used and the DT fails to authenticate
itself, then the PPP link will be dropped.
5: Using the appropriate PPP mechanisms, a suitable IP
address is negotiated between the LAP and the DT.
6: IP traffic can now flow across the PPP connection.
7: At any time the DT or the LAP may terminate
the PPP connection.
This profile is built upon the Generic
Access Profile.
As security in a wireless environment is of paramount
importance, steps must be taken to ensure adequate security in the profile.
Both the LAP and the DT must enforce that encryption is
operating on the baseband physical link while any PPP traffic is being sent
or received. The LAP and the DT will refuse any request to disable
encryption. Therefore, Bluetooth pairing must occur as a means of
authenticating the users.
A PIN or link key must be supplied, even if the default
PIN is used. The default PIN for LAN access is a zero length PIN. Failure to
complete the pairing process will prevent access to the LAN Access service.
The following modes are defined in the Generic
Access Profile. This profile requires the following support:
*Diagram Source: Courtesy of Bluetooth SIG, K9 Profile,
Table 3.1 , p 276
Two procedures are defined that make use of the pairing
procedure defined on LMP level. Either the
- user initiates the bonding procedure and enters the passkey with
the explicit purpose of creating a bond (and maybe also a secure
relationship) between two Bluetooth devices, or
- the user is requested to enter the passkey during the
establishment procedure since the devices did not share a common link key
beforehand.
In the first case, the user is said to perform ’bonding
(with entering of passkey)’ and in the second case the user is said to
’authenticate using the passkey’.
The following parameter is mandatory for the LAP.
Optionally it may be configurable by the LAP administrator.
Maximum number of users. Different products have
different capabilities and resource limitations that will limit the number of
simultaneous users that they can support. The administrator of the LAP may
choose to further limit the number of simultaneous users.
- Single-user mode is when the maximum number of users is
configured to allow only a single user. In this mode, either the DT or the
LAP may be the master of the piconet. Single-user mode means that a single
DT has exclusive access to a LAP.
- Multi-user mode is when the maximum number of users is configured
to allow more than one user. In this mode, the LAP must always become the
master of the piconet. If the DT refuses to allow the LAP to become master,
then the DT cannot gain access to the LAN.
There are practical limits concerning the amount of
users currently using a Bluetooth unit. The fewer simultaneous users there
are using a Bluetooth radio, the more bandwidth will be available to each. A
LAP can be restricted to a single user.
This procedure initiates the configuration of the
device as a LAP. This operation involves setting the following parameters:
- All the configurable parameters, (For example, maximum number of
users, discoverability mode, etc.)
- The required Bluetooth PINs and/or link keys.
- Any appropriate PPP configuration options (e.g. authentication,
compression) can be configured. In order to ensure interoperability, a LAP
shall not require connecting DTs to perform any PPP authentication, until
the LAP administrator has configured PPP authentication.
When initialization is complete, the device will be
able to accept PPP connections.
Normally the DT will initiate the establishment of a
connection to the LAN.
Step One:
- The first step is to select a LAP and a suitable PPP/RFCOMM service that
it provides. This selection may be done in one of the following ways:
- The DT user is presented with a list of LAPs that are within radio
range, and the services that they provide. The user can then select a
LAP/service from the list provided.
- The DT user is presented with a list of services that are being provided
by the LAPs that are within radio range. Where the same service is provided
by multiple LAPs (i.e. identical ServiceClass-IDs), the application may
choose to show the service only once. The user can then select a service
from the list provided. The DT will automatically select a suitable LAP
that provides the selected service.
- The DT user enters the name of the service that is required. The DT will
automatically select a suitable LAP that provides the required service.
- Some application on the DT automatically searches for and selects a
suitable LAP/service.
- Whatever means is used, the result of the selection process must be a
LAP that is within radio range and a PPP/RFCOMM service that it provides.
Step Two (Optional):
- The DT user (or application) is allowed to enter a Bluetooth
Authentication PIN or link key supplied by the application.
Step Three (Optional):
- The DT user (or application) is allowed to enter a username and password
for PPP authentication.
Step Four:
- When the user (or application) activates the connection, then a PPP
application is started, to attempt to establish a connection to the
selected access point/service.
Either the LAP or the DT may terminate the LAN
Connection at any time
This procedure stops the device from acting as a LAP.
- The PPP Server is shutdown
- Optionally, a product may take steps to prevent unauthorised Bluetooth
access at a later time by deleting some of the stored link keys.
PPP/RFCOMM operation in this profile is similar to PPP
operation in normal dial-up networking, except that this profile omits the
use of AT commands; PPP starts as soon as the RFCOMM link is established. By
contrast, in dial-up net-working, AT commands are used to establish the link,
then PPP starts communicating.
On the LAP, the existence of a PPP Server shall be
registered in the Service Discovery Database. A device in the DT role does
not register PPP in the Service Discovery Database. However, it is possible
for a device to be both a LAP and a DT; therefore the device could register
PPP in the Service Discovery Database as defined above.
PPP is a packet-oriented protocol, whereas RFCOMM
expects serial data streams. Therefore, the PPP layer must use the
serialisation mechanisms such as those defined in 'PPP in HDLC framing'
If there is no existing RFCOMM session between the LAP
and the DT, then the device initiating the PPP connection shall first
initialise RFCOMM. The device obtains the RFCOMM Server channel to use from
the service information it discovered earlier.
Using the Link Control Protocol (LCP), the LAP and DT
negotiate a PPP
Depending upon its capabilities and configuration, a
LAP may have multiple PPP sessions in operation simultaneously.
Optionally, a LAP may be configured to use one or more
of the PPP authentication protocols. These protocols allow a network
administrator to control access to the network. The use of these PPP
protocols does not form part of this profile. They are mentioned here for information
only.
PPP supports a number of authentication protocols including the following:
- PPP Challenge Handshake Authentication Protocol (CHAP)
- Microsoft PPP CHAP Extensions
- PPP Authentication
- PPP Extensible Authentication Protocol (EAP)
The following reasons will cause PPP to terminate the connection:
- User intervention.
- Failure of the RFCOMM/L2CAP connection. The RFCOMM/L2CAP connection may
fail for several reasons. For example, when the radio link has failed or
the device has been out of range for an excessive amount of time.
- Termination by the LAP, if the access point can no longer provide the
appropriate service. The reasons that would cause this are very dependent
on the implementation of the LAP, but they could include (a) detection of
duplicate IP addresses, (b) loss of connection to the LAN, (c) loss of
connectivity to the PPP Server, or (d) loss of connection to the required
IP subnet.
- Some implementation-specific policy decision made by an application that
is running on the LAP or the DT.
When the PPP connection is terminated, either by user
intervention or automatically by the LAP, then the PPP layer takes the
following steps:
- Gracefully terminate the IPCP connections. This will cause the IP
interface to be disabled.
- Gracefully terminate the LCP connections,
- Disconnect the RFCOMM connection (as defined in Serial Port Profile)
When the RFCOMM/L2CAP connection suddenly terminates,
then the PPP layer takes the following steps:
- Terminate the IPCP connections. This will cause the IP interface to be
disabled.
- Terminate the LCP connections.
All existing PPP connections are disconnected.The PPP
layer disables or removes the PPP service entry from the Service Discovery
Database.
This section describes the requirements on RFCOMM in
units complying with the LAN Access Profile.
This profile is built upon the Serial Port Profile. The
requirements defined in the Serial Port Profile Section 4, "RFCOMM
Interoperability Requirements," on page 177, apply to this profile.
- DevA (the connection initiator) is equivalent to DT and DevB is
equivalent to the LAP.
- All the mandatory requirements defined in the Serial Port Profile
Section 4 on page 177 'RFCOMM
Interoperability Requirements' are mandatory for this profile.
- All the optional requirements defined in the Serial Port Profile Section
4 on page 177 'RFCOMM
Interoperability Requirements' are optional for this profile.
In addition:
- In order to maximise packet throughput, it is recommended that RFCOMM
should make use of the 3 and 5 slot baseband packets.
- The speed of RFCOMM connections is not configurable by the user. RFCOMM
will transfer the data as fast as it can. The actual transfer rate will
vary, depending upon the other Bluetooth traffic on the baseband link. In
particular, the connection speed will not be artificially held at some
typical serial port value; e.g. 19200.
A LAP will be capable of providing one or more services for
connecting to a LAN. For example, different services could provide access to
different IP subnets on the LAN. The DT’s user must be able to choose which
of the LAN access services he/she requires.
Each LAP will provide one Service Class for PPP/RFCOMM
services. A LAP may contain multiple instances of this Service Class; e.g.
access to multiple subnets. Where the access point provides more than one
PPP/RFCOMM service, the service selection is based on service attributes.
These services are made public via the SDP.
This section describes the requirements on L2CAP in
units complying with the LAN Access Profile.
This profile is built upon the Serial Port Profile. The
requirements defined in the Serial Port Profile Section 5, "L2CAP
Interoperability Requirements," on page 179 apply to this profile.
- When reading [10], DevA (the connection initiator) is equivalent to DT
and DevB is equivalent to the LAP.
- All the mandatory requirements defined in the Serial Port Profile
section 5 on page 179 are mandatory for this profile.
- All the optional requirements defined in the Serial Port Profile Section
5 on page 179 are optional for this profile.
This section describes the requirements on Link Manager
in units complying with the LAN Access Profile.
This profile is built upon the Serial Port Profile. The
requirements defined in the Serial Port Profile Section 7, "Link Manager
(LM) Interoperability Requirements," on page 183 apply to this profile.
- When reading [10], DevA (the connection initiator) is equivalent to DT
and DevB is equivalent to the LAP.
- All the mandatory requirements defined in the Serial Port Profile
Section 7 on page 183 are mandatory for this profile.
- The following optional requirements defined in the Serial Port Profile
Section 7 on page 183 are mandatory for this profile.
In addition:
- For bandwidth reasons, it is advisable but not mandatory for both
devices to use multi-slot packets.
- When the LAP is configured in single-user mode (i.e. maximum number of
users is 1), then the LAP may be either the master or the slave of the
piconet.
- When the LAP is configured in multi-user mode (i.e. maximum number of
users is more than 1), then the LAP must be the master of the piconet.
The LAP must deny access to the PPP service if the DT fails to comply with
the requirements of this profile, as follows:
- Failure to complete the pairing process.
- Failure to comply with a request to enable encryption on the baseband
connection.
- Failure by the DT to comply with a request to perform a master/slave
switch.The LAP only requests a master/slave switch when it is configured in
multi-user mode. In this mode the LAP must be the master of the piconet.
The LAP must reject all attempts by the DT to perform the following
operation.
- Requesting that encryption be disabled.
- Requesting that the LAP switch to be a slave when the LAP is configured
to be in multi-user mode.
- Requesting that a new connection be made when the LAP already has its
configured maximum number of users.
This section describes the requirements on Link Control
in units complying with the LAN Access Profile.
This profile is built upon the Serial Port Profile. The
requirements defined in the Serial Port Profile, Section 8, "Link
Control (LC) Interoperability Requirements," on page 184, apply to this
profile.
- When reading [10], DevA (the connection initiator) is equivalent to DT
and DevB is equivalent to the LAP.
- All the mandatory requirements defined in the Serial Port Profile,
Section 8 on page 184, are mandatory for this profile.
- All the optional requirements defined in the Serial Port Profile,
Section 8 on page 184, are optional for this profile.
- The timer definitions defined in the Serial Port Profile, Section 8 on
page 184, are not used in this profile.
In addition:
- The Non-discoverable and General Discoverable Modes of the LAP (i.e. how
InquiryScan is used) are defined in the Generic Access Profile, 'Discoverability
Modes' section.
- In order to discover the nearby LAPs, a DT must use the General Inquiry
procedure defined in the Generic Access Profile, 'General
Inquiry' section.
Link Establishment is required for communication
between a LAP and a DT. The Link Establishment procedure is started as a
direct consequence of the user operations described in "Establish LAN
Connection" Section 4.3.
- The DT first performs a General Inquiry to discover what LAPs are within
radio range. Having performed the inquiry, the DT will have gathered a list
of responses from nearby LAPs.
- The DT sorts the list according to some product-specific criteria. The
LAN Access Point CoD contains a field called ‘Load Factor’. It is
recommended (but not mandated) that this field is used to sort the list.
- The DT shall start with the LAP at the top of the list and try to
establish a link with it. Any error or failure to establish a link shall
cause the DT to skip this LAP. The DT will attempt to establish a link the
next LAP in the list.
- If there are no more LAPs in the list, the DT shall not proceed with
further link establishment procedures. Link establishment has to be
reinitiated.
When the LAP is configured to allow multiple users,
then the LAP must be the master of the piconet. In this mode, the Management
Entity on the LAP ensures that the LAP remains the master of the Bluetooth
piconet.
While in multi-user mode, the LAP shall request that it
become the master of any new baseband physical link. If, for any reason, the
LAP cannot remain the master, then the baseband physical link shall fail. The
LMP allows a device to:
- request a master/slave switch, and also
- to refuse to comply with a request to perform a master/slave switch.
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.
|
