11
Personal Area Networks (PANs)
11.1 Introduction to PAN Technology and Applications
11.1.1 Historical Overview
The concept of a Personal Area Network (PAN) differs from that of other types of data
networks (e.g. LAN, MAN, WAN) in terms of size, performance and cost (Figure 11.1).
PANs are the next step down from LANs and target applications that demand short-range
communications inside the Personal Operating Space (POS) of a person or device. The term
POS is used to define the space in the near vicinity of a person or device and can be thought of
as a bubble that surrounds him. As the person goes through his regular daily activities, his
POS changes to include a number of different devices (such as cellular phones, pagers,
headphones, PC interfaces, etc.) with whom the ability for easy and transparent information
exchange would be useful. PANs aim to provide such ability in an efficient manner.
There exist a number of different communication mediums to choose for implementing a
PAN, such as electric and magnetic fields, radio and optical signal transmission. One of the
first research concepts for PANs dates back to an IBM research project in 1996 and is known
Figure 11.1 The various kinds of wireless networks
as ‘Near-field Intra-body Communication PAN (NIC-PAN)’ [1]. This approach uses the
human body as the communication medium, which can conduct electricity due to its natural
content of salt. According to this approach, NIC-PAN-compliant devices worn by a user can
communicate with each other through the user’s body, thus no wires are needed. Furthermore,
a user wearing such a device can initiate communication with another device located on
another user by means of a simple handshake. In order to transmit data between devices
attached to the users’ bodies or clothing, the NIC-PAN device transmitter charges and
discharges the human body, thus resulting in an oscillating potential appearing between
the body and the environment. These changes of potential are picked up by the receiving
NIC-PAN device and thus a communication channel is established. The electrical current
used in this approach is approximately 1 nA, which is much lower than the natural electrical
current of the human body. In the context of this research, a small prototype was built, which
achieved data rates around 2.4 kbps.
However, the NIC-PAN approach did not evolve into something more than a research

After the appearance of the Bluetooth and HomeRF initiatives, IEEE also decided to join
the area of developing specifications for PANs. Thus the 802.15 Working Group [2–5] was
Wireless Networks300
1
Since all PAN technology alternatives today employ wireless transmission, the terms PAN and WPAN are used
in this book synonymously.
formed in March 1999, with the responsibility of defining physical and MAC layer specifica-
tions for PANs having low implementation complexity and low power consumption.
Although Working Group 802.11, which deals with Wireless LANs, already existed, it
was decided that a new Working Group was needed for PAN standardization. This is attrib-
uted to the fact that there is a much greater concern over power consumption, size, and
product cost in PANs stemming from the demands for PAN devices compared to WLAN
devices:
†
Less size and weight, in order to be easily carried or worn for long periods of time. On the
other hand, the size and weight of WLAN cards is a matter of secondary importance. This
is because WLAN devices are typically either attached to portable computers, which of
course are not carried by users all of the time, or to fixed desktop PCs.
†
Lower cost, in order not to burden the total cost of the device. PAN devices aim to provide
wireless connectivity to commercial electronic appliances. In order to enable small device
size, PAN functionality will be integrated within the devices. To earn market acceptance,
the cost burden of PAN functionality on the total cost of the device should be small. Users,
on the other hand, can buy WLAN cards separately, thus the impact of their cost is less
important.
There are four Task Groups (TGs) inside Working Group 802.15:
†
TG1. This group is working on a PAN standard based on Bluetooth.
†
TG2. This group aims to facilitate coexistence of PAN and WLAN networks.

wants. However, automatic initiation of communication with the devices of nearby confer-
ence attendants may not be desirable for privacy reasons.
A person carrying a PAN-enabled device could find him-/herself in a diverse range of
situations, whether personal or professional, that demand information delivery through the
PAN device. Therefore, PAN devices should be compatible to enable information exchange
in all cases. Returning to the conference example, imagine two attendants wanting to
exchange information, discovering that their systems are not compatible and thus they
need to exchange the information on paper. In such case, the market community would
see PANs as a waste of time and money. Compatibility not only involves following a specific
PAN standard but also software compatibility. For example, the file formats on each of the
above devices should be able to be read by both devices.
PAN-enabled devices will be typically be carried by people for long periods of time. Thus,
they need to be small enough in order to be carried around without burdening. PAN devices
should therefore be as small and light as possible. Their energy efficiency should be enough in
order not to trouble the user with frequent recharging of batteries, while maintaining a low
device weight. Therefore, both low power consumption devices and high capacity batteries
are desirable. Furthermore, the efficiency in terms of size and weight should not come at an
expense over the price of PAN devices, in order to enable market acceptance.
Security issues are also crucial in PANs. Communications should be secure and difficult to
eavesdrop. Consider the case of a malicious user approaching pedestrians carrying PAN
devices. The unpleasant ‘Big Brother’ scenario of Orwell’s 1984 is obvious here and should
be as difficult to achieve as possible. It should be very hard for the malicious user to obtain
information regarding the unsuspected pedestrians, such as their names, home addresses, etc.
Therefore, robust authentication and encryption schemes should be developed in an effort to
prevent unauthorized initiation of communication and eavesdropping. These schemes should
be developed while keeping in mind the relatively low processing and power capabilities of
PAN devices which stem from the requirements for reduced cost, size and weight.
Finally, as in the case of all wireless networks human safety issues are of great concern. A
PAN device will typically be very close to the user for long periods of time and therefore even
small dangers could potentially have some impact on the user over time. The good thing here

via PAN APs.
†
Cordless telephony/headset. A user selects a contact name from a handheld, the handheld
wirelessly prompts the mobile phone in its proximity to dial the number and the audio
from the call is wirelessly forwarded to the user’s headset.
†
Home automation. Seamless transfer of commands to PAN-enabled home devices. For
example, automatic unlocking of the door upon the arrival of the user at his home, or
automatic tuning of the television to the user’s favorite channel upon his entrance to the
room.
†
Electronic purchases/reservations. PAN devices can be used to electronically book tick-
ets. For example, the PAN device of a user can be programmed to instantly initiate a
request for booking a ticket for a specific flight when the user enters the airport, thus
avoiding the long queues and waiting times of the traditional booking procedures.
†
Emergency situations. Medical devices with PAN interfaces can be used in order to
increase the safety of patients. For example, pacemakers could be monitored and
controlled remotely through PAN interfaces, or can be programmed to immediately call
an ambulance while also transmitting the patient’s medical condition in the case of a heart
attack or other serious health problem.
11.1.4 Scope of the Chapter
The remainder of this chapter provides a detailed presentation of technological alternatives in
the PAN area. Section 11.2 presents the Bluetooth specification and discusses, among others,
the way Bluetooth devices establish connections and exchange data. Furthermore, Blue-
tooth’s provisions on security and power management are discussed. Section 11.3 is a similar
discussion on the HomeRF standard. The chapter ends with a brief summary Section 11.4.
11.2 Commercial Alternatives: Bluetooth
11.2.1 The Bluetooth Specification
The Bluetooth specification 1.1 [6–9] comprises two parts: core and profiles. The core

11.2, audio data is not conveyed through L2CAP but is mapped directly to the baseband
layer. Thus, data for audio connections is exchanged directly between the baseband layers
of Bluetooth devices.
†
The service discovery layer runs the Service Discovery Prototcol (SDP), which is used in
Wireless Networks304
Figure 11.2 The Bluetooth protocol stack. Shaded layers implement Bluetooth-specific protocols
order for a Bluetooth device to learn about services on offer and neighboring device
information. Using SDP, neighbors of a device can be queried and if some requirements
are met, a connection can be established.
†
The RFCOMM layer runs a serial line RS-232 control and data signal emulation protocol.
It is used for cable replacement, offering transport capabilities over the wireless link to
applications that use serial lines as a transport mechanism.
†
The TCS layer defines call control signaling procedures for the establishment of voice and
data calls between Bluetooth devices.
†
The Host Controller Interface (HCI) is not a stack layer but an interface that provides the
means for accessing the Bluetooth hardware capabilities.
†
Layers that implement non-Bluetooth specific protocols (OBEX, WAP, etc.) are used to
enable high-layer application functionality.
The profiles part of the specification is used to classify Bluetooth applications into nine
application profiles, with each profile implementing only a certain set of the stack’s protocols.
This approach has received some criticism, which supports that the Bluetooth specification is
essentially a set of nine standards instead of one, with the number likely to rise as new
application profiles are added. However, the existence of application profiles aims to ensure
interoperability between Bluetooth devices. In order for a device to be certified for a specific
Bluetooth application, it has to follow the corresponding profile. Furthermore, the production

†
Headset profile. This application profile uses the serial port profile to provide connections
between Bluetooth-enabled computers or mobile phones and Bluetooth-enabled wireless
headset microphones.
†
Dial-up networking profile. This application profile uses the serial port profile to provide
dial-up connections via Bluetooth-enabled cellular phones.
†
Fax profile. This application profile uses the serial port profile to enable computers to send
a fax via a Bluetooth-enabled cellular phone.
†
LAN access profile. This application profile enables Bluetooth devices either to form small
IP networks among themselves or connect to traditional LANs through Access Points (APs).
†
Generic object exchange profile. This system profile defines the functionality needed for
Bluetooth devices to support object exchanges.
†
Object push profile. This application profile defines the functionality needed to support
‘pushed’ data. Examples of such information are advertisements and news distribution.
†
File transfer profile. This application profile enables file transfers between Bluetooth
devices.
†
Synchronization profile. This application profile enables automatic data synchronization
between Bluetooth devices. For example, it can be used to synchronize address books
between a desktop computer and a portable.
11.2.2 The Bluetooth Radio Channel
The Bluetooth radio channel [7], enabled by the radio layer, provides the electrical interface
for the transfer of Bluetooth packets over the wireless medium. The radio channel operates at
the 2.4 GHz ISM band by performing frequency hopping through a set of 79 (US and Europe)

master’s clock value and its 48-bit device ID. The way the hopping sequence is used and the
starting point within that sequence is selected is shown in Figure 11.6. The first parameter
defines the hopping sequence used for FHSS transmission inside the piconet. The second
parameter is derived from the native clock of the master and defines the phase within that
sequence. Slave to slave transmission is not supported inside a piconet. If two slaves need to
communicate, they either have to form a separate piconet in which one of them is the master,
or use a higher layer protocol, such as IP in order to relay messages through the piconet’s
master.
A number of piconets can coexist in the same area. This coexistence is enabled due to the
use of FHSS transmission. Since the hopping sequences used in Bluetooth are pseudorandom,
different coexisting piconets will use different hopping sequences, resulting in a low prob-
Personal Area Networks (PANs) 307
Figure 11.4 Power classes for Bluetooth devices
ability of hop collisions. Still, if such a case occurs, a Bluetooth device can recognize and thus
ignore packets originating from collocated networks by checking the access code field on the
received packets which is different for every piconet, as we explain later. However, when a
large number of piconets coexist in the same area, this probability rises and the performance
of each piconet degrades.
A collection of overlapping piconets is called a scatternet. A scatternet will typically
contain devices that participate in one or more piconets. Devices participating in two or
more piconets are known as bridge devices and participate in each piconet in a time-sharing
manner. After spending its time inside a piconet, a bridge device will change its hopping
sequence to that of the new piconet in order to join it. Furthermore, it will select the starting
point within that sequence based on the clock value of the master of the new piconet. By
alternating among several piconets and buffering packets, bridge nodes can forward packets
from one piconet to another. A bridge node that participates in several piconets can be either:
†
Slave in all the piconets. In this case, when leaving the old piconet, the slave has to inform
the master for the duration of its absence.
†

listener, by transmitting a signal on each hop and listening between successive transmissions
for an answer. The term Frequency Synchronization delay (or FS delay) refers to the time
elapsed until the sender (A in this case) transmits at the frequency the receiver (B) is currently
Personal Area Networks (PANs) 309
Figure 11.7 A scatternet formed by four piconets