Personal Area Networking Profile
The Personal Area Networking (PAN)
Profile describe how two or more Bluetooth enabled devices can form an
ad-hoc network and how the same mechanism can be used to access a remote
network through a network access point. The profile roles contained in
this document are the Network Access Point Profile, Group Ad-hoc Network,
and Personal Area Network User.
Network access points can be a traditional
LAN data access point while Group Ad-hoc Networks represent a set
of devices that are only attached to one another.
For more details : Download the PAN Profile from the Bluetooth.org
website.
The PAN profile defines a means of enabling
Bluetooth devices to participate in a personal area network. Completely
un-modified Ethernet payloads can be transmitted using the Bluetooth
Network Encapsulation Protocol (BNEP) to exchange packets between
Bluetooth devices.
The profile defines how PAN is supported in the
following situations:
- Ad-hoc IP networking by two or more Bluetooth devices in a single
piconet.
- Network access for one or more Bluetooth devices.
For this profile, two general scenarios are
discussed:
- Network access points,
- Group Ad-hoc Networks.
Each of the scenarios has unique network
architecture and unique network requirements, but all are various
combinations of a PAN.
Network Access Points
In this scenario, the radio and host controller
appear to be a direct bus connection to a network interface device with
network access. A network access point is a device that contains one or
more Bluetooth radio devices and acts as a bridge, proxy, or a router
between a network (10baseT, GSM, etc) and the Bluetooth network. Each
network access point can allow one or more computing devices to gain
access to it, and each of these computing devices will have access to all
of the LAN’s shared resources. Network access points will provide access
to other networks technologies such as, ISDN, Home PNA, Cable Modems, and
cell phones.
Image reprinted from Bluetooth PAN Profile, Figure 2
, page 14
Group Ad-hoc Networks
Group ad-hoc networking is a collection of mobile
hosts that co-operatively create an ad-hoc wireless network without the
use of additional networking hardware or infrastructure. In addition, the
PAN profile focuses on the following simple personal ad-hoc networking
scenarios consisting of a single Bluetooth piconet with connections
between two or more Bluetooth devices.
Image reprinted from Bluetooth PAN Profile, Figure 3
, page 15
Network access points and group ad-hoc networks are
two different services. Network access points provide network services to
each of the Bluetooth devices connected. Group ad-hoc networks are
designed to allow one or more Bluetooth devices to become part of an
ad-hoc network. Both Network Access Points and Group Ad-hoc Networks
provide the facility for applications to use IP and other networking
protocols.
The figures below show the protocols and entities
used in each of these profile.
Network Access Point Profile Stack:
Image reprinted from Bluetooth PAN Profile, Figure 4
, page 16
Group Ad-hoc Network Profile Stack:
Image reprinted from Bluetooth PAN Profile, Figure 5
, page 16
The following roles are defined for the PAN profile.
Network Access Point (NAP) and NAP service - A
Bluetooth device that supports the NAP service is a Bluetooth device
that provides some of the features of an Ethernet bridge to support
network services. The device with the NAP service forwards Ethernet
packets between each of the connected Bluetooth devices, referred to as
PAN users, see below. A device with the NAP service will simply be
called a NAP. The NAP and the PAN User exchange data using the Bluetooth
Network Encapsulation Protocol (BNEP). The device with the NAP service
has an additional network connection to a different network media in
which the Ethernet packets are either exchanged via Layer 2 bridging or
Layer 3 routing mechanism.
Group Ad-hoc Network (GN) and GN service - A
Bluetooth device that supports the GN service is able to forward
Ethernet packets to each of the connected Bluetooth devices, the PAN
users, as needed. The Group Ad-hoc Network and the PAN User exchange
data using the Bluetooth Network Encapsulation Protocol (BNEP) [1].
Group Ad-hoc Networks do not provide access to any additional networks.
Instead, Group Ad-hoc Networks are intended to allow a group of devices
to form temporary network and exchange information.
PAN User (PANU) – This is the Bluetooth device that
uses either the NAP or the GN service. PANU supports the client role for
both the NAP and GN roles.
The presentation of this profile will continue with
the simplifying assumption that each device involved with each of the
profile has a single Bluetooth radio.
The following three examples are brief summaries of
the possible interactions between two Bluetooth devices that support the
PAN profile.
The first example describes how a PANU finds,
connects, and uses a NAP and its network services. Basically this involves
the PANU setting up a Bluetooth connection with a NAP, then creating an L2CAP
channel to initialise an BNEP connection. Ethernet traffic can then flow
across the link (once the PANU has done various other things such as
obtaining an IP address)
The second example describes how a PANU finds,
connects, and uses a GN. Basically this involves the PANU setting up a
Bluetooth connection with a GN, then creating an L2CAP channel to
initialise an BNEP connection. Ethernet traffic can then flow across the
link. As the GN will not provide networking services each of the PANU's
must perform various tasks to function without this. The GN will forward
all Ethernet packets to each of the connected PANUs.
The final example describes how a GN finds,
connects, and then offers GN services to the PANU. Basically this involves
the GN setting up a Bluetooth connection with a PANU, then creating an
L2CAP channel to initialise an BNEP connection. Ethernet traffic can
then flow across the link. As the GN will not provide networking services
each of the PANU's must perform various tasks to function without this.
The GN will forward all Ethernet packets to each of the connected PANUs.
Subsequent sections in the PAN profile provide more
detail for each of the previous examples.
It is recognised that the security provided by fixed
cables in wired networks has to be replaced by some other security means
in wireless environment. In the Bluetooth Spec security mechanisms are
specified to provide authentication and encryption at Baseband
level at link layer. All devices should support Bluetooth security
mechanisms. To provide link layer security a method for establishing
secure link keys between the communicating devices must be used. One such
method is to use Bluetooth PIN values.In PAN, link layer security can also
be based on the authentication methods provided by IEEE 802.1X.
See Section 3.2 of the PAN Profile to determine what
operational modes (e.g Discoverability modes, Connectability modes,
Pairing modes) are required for the PAN Profile.
There are several application layer requirements for
either the NAP, GN or PANU. they are:
- Initialization of NAP/GN service: This procedure
initiates the configuration of the device as a NAP/GN.
- Shutdown of NAP/GN service: This procedure stops
the device from acting as a NAP/GN.
- Establish NAP/GN service Connection: This procedure
is performed by a PANU connection to a NAP/GN.
- Lost NAP/GN Service Connection: When the NAP/GN
service connection is lost, the actions taken by the device are
dependent on the role of the device.Two different ways this can occur:
Lost NAP/GN Service Connection for PANU: If the NAP/GN Service
connection is lost for any reason, then the PANU device response to
the lost connection is dependent on that device.Lost NAP/GN
Service Connection for NAP/GN: If the NAP/GN Service connection
is lost (i.e. the connection becomes disconnected, due to link loss,
supervision timeout, etc.) for any reason, then the NAP/GN device
actions in response to the connection loss are also dependent on that
device.
- Disconnect NAP/GN Service Connection: Either the
NAP/GN or the PANU may terminate the connection at any time
- Management Information Base (MIB) : Devices that
support the NAP service may have MIBs. If the NAP/GN has multiple
Bluetooth radios, then the MIB should allow for each radio to be
separately configured.
For the NAP/GN service, the NAP/GN and the PANU
exchange data using the Bluetooth Network Encapsulation Protocol. The
NAP/GN performs Ethernet Bridge functions to forward Ethernet packets from
one PANU to another PANU or from a PANU to another network. Ethernet
Bridge functions required for NAP/GN in role for this profile is a subset
of the IEEE 802.1D Bridge standard.
The following text together with the associated
sub-clauses defines the mandatory requirements with regard to the PAN
profile.
On the NAP/GN, the existence of a
NAP/GN Service must be registered in the Service Discovery Database. PANU
may also register a PANU service.
The NAP, GN, or PANU obtains
the appropriate L2CAP PSM value to use from the service information it
discovered earlier. It then requests the creation of an L2CAP channel with
the NAP, GN, or PANU.
Each Ethernet packet is transmitted as a single
L2CAP packet. Ethernet packets are transmitted as the L2CAP payload
between Bluetooth devices using the Bluetooth Network Encapsulation
Protocol.
The Bluetooth Network Encapsulation Protocol
is used to exchange data between the NAP/GN and each PANU. The operation
of a NAP/GN executing the NAP/GN service follows a small subset of the
IEEE 802.1D standard.
There are various reasons that can cause the
connection to be terminated.
- User intervention,
- failure of the BNEP connection,
- termination by the NAP, GN, or PANU if the device can no longer
provide the appropriate service,
- security failure,
- some implementation specific policy decision made by an application
that is running on the NAP/GN or the PANU.
A NAP, GN, or PANU stops advertising an active NAP,
GN, or PANU service and all existing connections to the NAP, GN, or PANU
service are terminated.
The 802.1D standard states that Ethernet broadcast
and multicast frames must be transmitted to all operational bridge ports.
This means that a NAP/GN shall transmit the frame separately to each
connected PANU. It is recognised that this is wasteful of the piconet’s
bandwidth when there is more than one PANU. It is left to the product
manufacturers to develop suitable means for reducing the amount of
un-necessary traffic sent to each PANU.
There are two sets of IETF RFCs used within the PAN
profile:
The mandatory set of IETF RFCs required for
communication is broken into two categories depending on whether the
network layer is based on IP Version 4 or IP Version 6.See Section 6.1 of
the PAN profile for details.
The recommended set of IETF RFCs listed in Section
6.2 of the PAN Profile are recommended for communication, in particular
for communication across subnet boundaries.These are also broken into two
categories, depending on whether the network layer is based on IP Version
4 or IP Version 6.
The IP address length, as well as the technique used
by a node to obtain an IP address is dependent on the version of IP
(IPv4 or IPv6) the node is executing.
For Name Resolution, Bluetooth PAN devices SHALL
comply with the Multicast DNS. This
draft will be temporally used until Multicast DNS becomes a standard draft
RFC, at which time all devices supporting the Bluetooth PAN profile MUST
comply with that RFC.
The Bluetooth specifications provide a set of
security features that enable Bluetooth equipped devices to authenticate
other Bluetooth equipped devices upon connection to a particular device or
service, as well as protect transmitted data using encryption. This
section of the profile contains suggested security mechanisms for the
Bluetooth PAN profile. It is strongly recommend that the recommended
security mechanisms be used. The two mechanisms for this, authentication
and encryption, operate on Baseband level. Authentication relies on a link
key, from which the encryption key is derived. The link key between two
Bluetooth equipped devices can be based on supply of a PIN in both
devices. Alternatively, it can be provided directly by an application. On
top of the Bluetooth Baseband security mechanisms, other security
mechanisms may be applied, such as provided by 802.1X, IPSEC, TLS/WTLS,
application level security, etc.
As the PAN profile is dependent on the Generic
Access Profile, the specifications concerning security from the Generic
Access Profile (GAP) are also relevant for the PAN profile. GAP
specifies three security modes, here identified as the Bluetooth
Security Modes:
- Non-secure: a device will not initiate any security
procedure: For a NAP/GN this means that the NAP/GN service is
accessible to all devices, no Bluetooth security procedures are
initiated by the NAP/GN/PAN device. This does not prevent a NAP/GN to
enforce higher layer security mechanisms.
- Service-level enforced security: a device does
not initiate security procedures before channel establishment at L2CAP
level: For the PAN profile, this security mode is expanded to the
more general PAN service-level enforced security mode where the
security procedures (Bluetooth Baseband security and/or higher layer
security) are initiated upon accessing a PAN service through NAP or GN
.
- Link-level enforced security: a device initiates
security procedures before the link set-up at LMP level is completed: The
operation of devices relating to these security modes within of PAN
profile is described below in more detail. A NAP/GN operating in this
mode can either request authentication only or both authentication and
encryption. On top of Bluetooth security, higher layer security
mechanisms may be applied.
The NAP/GN operates in one of the Bluetooth security
modes (see above). Within the PAN profiles, Bluetooth security mode 2
(service-level enforced security) is expanded to the PAN service-level
enforced security mode, including both Bluetooth and higher layer (802.1X,
IPSEC) security mechanisms. This mode is composed of the PAN Authorisation
Modes and the PAN Secrecy Modes, both further described below.
- PAN Authorisation Modes: The PAN Authorisation modes specify
the level of authorisation required to get access to a PAN. The PAN
Authorisation Mode is set by the NAP/GN, and indicated in the
respective Service Record.
- PAN Secrecy Modes: The PAN Secrecy Modes specify the level of
protection of traffic within the PAN. The level of secrecy for a PAN
is set by the NAP/GN. The PAN operates in one of the following two
modes: clear mode meaning that no encryption is
applied, or encrypted mode meaning that encryption is
enforced on all communication within the PAN.
A PANU also operates in one of the Bluetooth
security modes as defined above. Any PANU participating in a Bluetooth PAN
may demand a certain level of security and subsequently reject a lower
level of security if these demands are not met. This results in
termination of the communication channel at the relevant level, i.e.,
relevant to the applied security mechanism. E.g. if the request for
Bluetooth authentication is not met and the PANU is configured in security
mode 3, the PANU must terminate the Bluetooth connection with the NAP/GN.
Similarly, if 802.1X authentication fails, the L2CAP channel for BNEP must
be terminated.
Bluetooth Baseband security can be used to provide
security at link layer where it operates. Similar to other link layer
communication protocols, such as IEEE 802.1X, it does not provide
end-to-end security.
A device supporting the PAN profile could be capable
of providing each of the PAN services. For example, a device could support
the NAP, GN and PANU service. If multiple services are advertised by a
device, the PANU’s user or an application must be able to choose which
of the PAN services it intends to use.The service selection is based on
service attributes. These services are made public via the SDP. NP, GN and
PANU service records are listed in Section 8.1 of the PAN Profile.
There are several mandatory requirements with regard
to the PAN profile.
In the PAN profile, only connection-oriented
channels shall be used.
Typically, the PANU will issue an L2CAP Connection
Request within the execution of the PAN profile. However, there may be
situations when the NAP/GN makes the connection request.
- Maximum Transmission unit: The PAN profile require a minimum
MTU as required by the BNEP specification
- Flush Time-out: Bluetooth networking encapsulation protocol
is recommended to be used over a reliable L2CAP channel. For some
networking protocols, such as many real-time protocols, a 100%
reliable is undesirable. The flush time-out value shall be set to its
default value 0xffff for a reliable L2CAP channel, and may be set to
other values if 100% reliability is not desired.
- Quality of Service: Negotiation of Quality of Service is
optional in the PAN profile.
L2CAP connectionless broadcasts are not used in the
PAN profile.
In addition to the requirements on supported
procedures stated in the Link Manager specification itself (see Link
Manager Protocol), the PAN profile also supports the following
features:
Image reprinted from Bluetooth PAN Profile, Figure 9
, page 48
If a unit tries to use a mandatory feature, and the
other unit replies that it is not supported, then the NAP/GN service shall
be denied.
The NAP/GN shall deny access to the NAP/GN service
if the PANU fails to comply with the mandatory requirements of the PAN
profile. If the NAP/GN initiates the connections to the PANU then the
NAP/GN shall comply with the requirements of the PAN profile, or the PANU
shall disconnect the connection.there are also several other additional
reasons where the device will deny access to the PAN service, see Section
10.3 of the PAN Profile for more details.
There are several mandatory Link Control
requirements with regard to the PAN profile.
Table 10 in the PAN Profile lists all capabilities
on the LC level.
When inquiry is invoked in NAP/GN or PANU, it should
use the General Inquiry, see GAP Profile. NAP/GN or PANU may inquire
within the execution of the PAN profile.
For inquiry scan, (at least) the GIAC shall be used,
according to one of the discoverable modes defines in the GAP Profile.
Depending on the paging class indicated by a device,
the other device shall page accordingly. NAP/GN or PANU may page within
the execution of the PAN profile. The paging step shall be skipped in the
PANU or NAP/GN when execution of the PAN profile begins when there already
is a baseband connection between the PANU and the NAP/GN.
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.
Devices that support the PAN profile shall set the
Networking bit in the service class field on the CoD.
The following text together with the associated
subclasses defines the mandatory Management Entity Procedures that
are required with regard to the PAN profile.
- Link Establishment: The Management Entity controls
initialization of the connection with NAP/GN service.
- Single/Multi-user mode: When the NAP/GN is
configured to allow multiple users, then the NAP/GN must be the master
of the piconet. In this mode, the Management Entity on the NAP/GN
shall ensure that the NAP/GN remains the master of the Bluetooth
piconet.
- Encryption: The Management Entity on the NAP/GN may
ensure that the baseband connection is always encrypted. If, for any
reason, the link cannot be encrypted,
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 Bluetooth
Specification.
|
