Radio Baseband LMP HCI L2CAP RFCOMM SDP Profiles

K9 - LAN Access Profile

    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.

        Table Of Contents

9.1 Profile Overview
9.1.1 Scope
9.1.2 Protocol Stack & Entities Used
9.1.3 Roles/Configurations
9.1.4 Profile Scenarios
9.1.5 Profile Operation/Fundamentals
9.2 User Interface Aspects
9.2.1 Security
9.2.2 Generic Modes
9.2.3 Additional Parameters
9.3 Application Layer Procedures
9.3.1 Initialization : LAN Access Point (LAP) Service
9.3.2 Establish LAN Connection
9.3.3 Disconnect LAN Connection
9.3.4 Shutdown : LAN Access Point (LAP) Service
9.4 PPP Operation
9.4.1 Initialise PPP
9.4.2 Establish PPP Connection
9.4.3 PPP Authentication Protocols
9.4.4 Disconnect PPP Connection
9.4.5 Shutdown PPP
9.5 RFCOMM Operation
9.6 Service Discovery
9.6.1 SDP Service Records
9.7 L2CAP
9.8 LMP
9.8.1 Profile Errors
9.9 Link Control
9.10 Management Entity Procedures
9.10.1 Link Establishment
9.10.2 Maximum Number of Users

 

9.1  Profile Overview

9.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).

9.1.2   Protocol Stack & Entities Used

   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.

9.1.3  Roles/Configurations

    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.

9.1.4  Profile Scenarios

    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.

 

9.1.5  Profile Operation/Fundamentals

    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.

 

9.2  User Interface Aspects

    This profile is built upon the Generic Access Profile.

9.2.1  Security

    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.

9.2.2  Generic Modes

    The following modes are defined in the Generic Access Profile. This profile requires the following support:

generic_modes_table.gif (21345 bytes)

*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

  1. 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
  2. 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’.

9.2.3  Additional Parameters

    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.

 

9.3  Application Layer Procedures

9.3.1  Initialization : LAN Access Point (LAP) Service

    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.

9.3.2  Establish LAN Connection

    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.

9.3.3  Disconnect LAN Connection

    Either the LAP or the DT may terminate the LAN Connection at any time

9.3.4  Shutdown : LAN Access Point (LAP) Service

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.

 

9.4  PPP Operation

    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.

9.4.1  Initialise PPP

    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'

9.4.2  Establish PPP Connection

    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.

9.4.3  PPP Authentication Protocols

    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)

9.4.4  Disconnect PPP Connection

The following reasons will cause PPP to terminate the connection:

  1. User intervention.
  2. 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.
  3. 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.
  4. 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:

  1. Gracefully terminate the IPCP connections. This will cause the IP interface to be disabled.
  2. Gracefully terminate the LCP connections,
  3. 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:

  1. Terminate the IPCP connections. This will cause the IP interface to be disabled.
  2. Terminate the LCP connections.

9.4.5  Shutdown PPP

    All existing PPP connections are disconnected.The PPP layer disables or removes the PPP service entry from the Service Discovery Database.

 

9.5  RFCOMM Operation

    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:

  1. In order to maximise packet throughput, it is recommended that RFCOMM should make use of the 3 and 5 slot baseband packets.
  2. 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.

 

9.6  Service Discovery

   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.

9.6.1  SDP Service Records

    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.

 

9.7  L2CAP

    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.

 

9.8  LMP

    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.

9.8.1  Profile Errors

The LAP must deny access to the PPP service if the DT fails to comply with the requirements of this profile, as follows:

  1. Failure to complete the pairing process.
  2. Failure to comply with a request to enable encryption on the baseband connection.
  3. 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.

  1. Requesting that encryption be disabled.
  2. Requesting that the LAP switch to be a slave when the LAP is configured to be in multi-user mode.
  3. Requesting that a new connection be made when the LAP already has its configured maximum number of users.

 

9.9  Link Control

    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:

  1. 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.
  2. In order to discover the nearby LAPs, a DT must use the General Inquiry procedure defined in the Generic Access Profile, 'General Inquiry' section.

 

9.10  Management Entity Procedures

9.10.1  Link Establishment

    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.

9.10.2  Maximum Number of Users

    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.