Wireless Private Area Network — Bluetooth

Vijay K. Garg, in Wireless Communications & Networking

19.4 Definitions of the Terms Used in Bluetooth

Piconet. A collection of devices connected via Bluetooth technology in an ad

hoc fashion. A piconet starts with two connected devices, such as a PC and
cellular phone, and may grow to eight connected devices. All Bluetooth devices
are peer units and have identical implementations. However, when establishing a
piconet, one unit will act as a master for synchronization purposes, and the
other(s) as slave(s) for the duration of the piconet connection.

Scatternet. Two or more independent and no synchronized piconets that

communicate with each other. A slave as well as a master unit in one piconet can
establish this connection by becoming a slave in the other piconet.

Master unit. The device in the piconet whose clock and hopping sequence are
used to synchronize all other devices in the piconet.

Slave units. All devices in a piconet that are not the master (up to seven active
units for each master).

MAC address. A 3-bit medium access control address used to distinguish

between units participating in the piconet.

Parked units. Devices in a piconet which are time-synchronized but do not have
MAC addresses.

Sniff and hold mode. Devices that are synchronized to a piconet, and which
have temporarily entered power-saving mode in which device activity is
reduced.

1
Network Connectivity
Peter Barry, Patrick Crowley, in Modern Embedded Computing, 2012

Protocol Details

The Bluetooth architecture features a piconet as its basic unit of organization. A piconet
consists of one master Bluetooth device and up to seven active slave devices within
radio range of the master, typically 10 meters or less. All communication is between
master and one slave, and time division multiplexing is used as the master switches
rapidly between slaves. Bluetooth version 2.0 and above support link rates on the order
of 3 Mbps.

Multiple piconets can exist and overlap; when connected via a bridge node, the resulting
internetwork is called a scatternet. Master nodes can cause slave nodes to transition to
an inactive low-power state, and a piconet can contain a large number, 255, of these
nodes.

As a networking technology, Bluetooth is peculiar in that it defines the applications for

which it can be used. It does so via the definition of profiles, which outline both the
application and the subset of Bluetooth features needed to implement it. This profile-
based approach arose, presumably, as a compromise between providing rich capabilities
and executing in the context of a resource-constrained, battery-operated handset.

Table 12.3 lists some, but not all, of the profiles currently supported in Bluetooth.

Table 12.3. Some Bluetooth Application Profiles

Profile Description
Advanced Audio Distribution Streams high-quality audio
Audio/Video Remote Control Controls A/V devices such as TVs and Blu-ray players
Basic Imaging Sends, receives, resizes images
Basic Printing Sends text messages, emails, and other items to printer
Cordless Telephony Enables the handset to serve as a cordless landline phone
Fax Provides communication between a phone and PC fax
File Transfer Shares file systems with other devices
Headset Hands-free voice communication with a wireless headset
Intercom Enables push-to-talk between handsets
LAN Access Enables access to a LAN
Service Discovery Discovers services available on a remote device
Synchronization Synchronizes personal information with another device
Video Distribution Allows the transport of a video stream

The Bluetooth protocol stack, illustrated in Figure 12.11, differs from the TCP/IP
protocol stack discussed earlier. The lowest three levels, radio, baseband, link manager
(LMP), and link control adaptation (L2CAP), roughly correspond to the physical and
link-level protocols we discussed in the context of the Internet architecture and
Ethernet.

2
Sign in to download full-size image

FIGURE 12.11. Bluetooth Protocol Stack.

The other stack components differ. First, above RFCOMM (a layer that emulates a
standard serial port) a TCP/IP stack can be found. Also, audio (which corresponds to
voice data) has its own path through the stack that avoids further processing. The other
layers, vCard, AT commands, TCS BIN, and SDP, are examples of profiles that have a
discrete presence at the application layer.

Wireless Local Area Networks

Vijay K. Garg, in Wireless Communications & Networking, 2007

21.12.1 Packet Error Rate (PER) from N Neighboring Bluetooth Piconets

Synchronous mode: The probability that one interfering Bluetooth piconet

selects the same channel as the desired piconet is 1/79. The probability for a
Bluetooth packet to be transferred successfully for synchronous mode is (1
−1/79) = 78/79

Asynchronous mode: The duration of a single slot packet is 366 μs and the
duration of a slot is 625 μs. If r is equal to 366/625, there is a probability of 2(1
– r) that only the preceding or the following slot is vulnerable and a probability

3
 of (2r −1) that both preceding and following slots are vulnerable. Hence the
probability of the desired piconet not being disturbed by one advisory piconet is
given as:

(21.1)PsUR =2(1 − r) ⋅ (7879) + (2r − 1) ⋅ (7879)2

The PER due to N neighboring Bluetooth piconets for synchronous and asynchronous
modes are given as:

(21.2)(PER)syn = 1 − (7879)N
(21.3)(PER)asyn=1−[2(1−r)⋅(7879)+(2r−1)⋅(7879)2]N=1−(PSUR)N

Introducing Bluetooth Applications

In Bluetooth Application Developer's Guide, 2002

Using Power Control

We must also consider the respective power class of our Bluetooth devices. To enable
all classes of device to communicate in a piconet without damage to the RF front ends
of the lower power devices, a method of controlling the output power of Class 1
(100mW) devices is required.

Transmit power control is mandatory for Bluetooth devices using power levels at or
above 4 dBm. Below this level (i.e., all Class 2 and 3 modules), it is optional. To
implement a power control link, the remote device must also implement a Receive
Signal Strength Indicator (RSSI). A transceiver that wishes to take part in a power-
controlled link must be able to measure its own receiver signal strength and determine if
the transmitter on the other side of the link should increase or decrease its output power
level.

To set up a power controlled link, the transmit side must support Transmit Power
Control and the receive side must support RSSI. Support is indicated in the Locally
Supported Features (Bluetooth Spec 1.1 Part C (LMP) Section 3.11). The RSSI need
only be able to compare the incoming signal strength to two levels: the Upper and
Lower Limits of the Golden Receiver Range. The Lower Limit is between −56 dBm and
is 6 dB above the receive sensitivity (0.1 percent BER level) for the particular
implementation. The Upper Limit is 20 dB +/− 6 dB above this. The RSSI level is
monitored by the receive side's Link Controller. When it strays outside the Golden
Receiver range, the Link Manager is notified. A message is sent to the transmit side,
requesting an increase or decrease in transmit power to bring the RSSI back in line. If
the transmitter is a master, it must maintain separate transmit powers for each slave.

Host Controller Interface (HCI) commands exist to find out the current transmit power
and RSSI level, but they are for information only. Layers above the Link Manager are
not directly involved in power control. The implication of this is that it is perfectly
possible to sit a Class 1 module transmitting at +20 dBm right next to another module
which does not support RSSI and not limit the first's transmit power. If the second
module's maximum receivable level is the Bluetooth spec of −20 dBm, there is every

4
chance its RF front end will be overloaded. RSSI, although not mandatory, is highly
recommended, as is a large power control range implemented on all modules, not just
Class 1.

Figure 1.12 illustrates interfering Bluetooth piconets, but the principle holds true for
coexisting networks of different technologies. Devices that are close to one another turn
their power down and do not interfere with devices at a distance. Devices transmitting a
long distance have to turn their power up to reach one another, which generates more
interference and affects more devices. The hypothesis for us is ultimately to persuade
our consumers to site devices intelligently. The home user is typically unaware of the
implications of radio interference and will not position their devices for best
performance!

Sign in to download full-size image

Figure 1.12. Interfering Piconets

Wireless personal area networks

Alan Bensky, in Short-range Wireless Communication(Third Edition), 2019

[Link] Park mode

5
Park has the greatest potential for power conservation, but as opposed to hold and sniff,
it is not a directly addressable member of the piconet. While it is outside of direct
calling, a slave in park mode can continue to be synchronized with the piconet and can
rejoin it later, either on its own initiative or that of the master, in a manner that is faster
than if it had to join the piconet from scratch. In addition to saving power, park mode
can also be considered a way to virtually increase the network’s capacity from eight
devices to 255, or even more. When entering park mode, a slave gives up its active
piconet address and receives an 8-bit parked member address. It goes into low-power
mode but wakes up from time to time to listen to the traffic and maintain
synchronization. The master sends beacon transmissions periodically to keep the
network active. Broadcast transmissions to all parked devices can be used to invite any
of them to rejoin the network. Parked units themselves can request re-association with
the active network by way of messages sent during an access window that occurs a set
time after what is called a “beacon instant.” A polling technique is used to prevent
collisions.

Park mode was removed in Version 5 of the Bluetooth specification.

Designing an Audio Application

In Bluetooth Application Developer's Guide, 2002

Using ACL Links for High-Quality Audio

So far, we have looked at voice links that use the HV packet types transmitted in
reserved bandwidth provided by SCO links. The SCO links support the same sort of
voice quality you would expect from a cellular phone. This is great for applications such
as mobile phone headsets, but not acceptable for applications that require higher audio
bit rates.

Obviously, with a maximum bit rate of 64 Kbps, a Bluetooth SCO link can't serve audio
CD quality sound (1411.2 Kbps). For any high bit rate audio application (for example, a
portable Bluetooth device playing MP3 music), the SCO channels will be inappropriate.

However, with suitable compression, it would be technically feasible to send high bit
rate audio packets using asymmetric ACL channels. This allows us to get the maximum
bandwidth from the Bluetooth link by using an asymmetric ACL link that can provide
up to 723.2 Kbps, as shown in Table 9.2.

Table 9.2. Bluetooth Communication Channel Support in Master-Slave Pairs

Channel Empty Cell Maximum Data Rate

Maximum Number Type Configuration Transmitting Receiving
732.2 Kbps 57.6 Kbps
Asymmetric data
7 Asynchronous (ACL) 57.6 Kbps 732.2 Kbps
Symmetric data 433.9 Kbps
3 Synchronous (SCO) Voice 3 × 64 Kbps

6
The SCO links provide guaranteed latency on the link, but do not retransmit lost or
errored packets. By contrast, the ACL link provides guaranteed delivery of packets, but
as this is done through retransmissions, there are no guarantees on latency (delay).

There are two levels of choice when configuring Bluetooth audio links. First, you must
choose whether to use the Bluetooth audio Codecs and the SCO links, or send
compressed audio across the ACL links. For real-time duplex voice communications,
you should always choose the SCO links because of their guaranteed latency. For high
bit-rate simplex audio such as that required for music, the SCO links will not provide
the required quality and compressed audio must be sent across the ACL links.

Case Study Example

Let's assume audio data streaming in a wireless point-to-point network, which includes
a PC, a loudspeaker, and a subwoofer. The PC playing MP3-coded music is the
piconet's master; the speaker and the subwoofer are both slaves.

Because we are listening to music, the SCO channel is too low quality, so we want to
send packets across the ACL link. The ACL link is designed for bursty data, not for
audio, so it will retransmit any packets which are subject to errors. This introduces delay
into the link.

In order to cope with the delay, we need to buffer packets at the receiver—that way we
can feed a steady stream of information to the MP3 decoder even if there are delays in
the signal.

This has important implications for our application. We must ensure we use
compression that allows all information to get through the channel even if there are
errors. Though theoretically we have 732.2 Kbps to share between our slaves, in
practice some of that capacity will be used up by errors and retransmissions, so our
MP3 encoding must compress to less than the theoretical maximum channel capacity.

Once you have chosen the link type suitable for your application, you must configure
the link by choosing a packet type for it. For ACL links, you should always allow the
baseband to choose the correct packet type for the current environment. To do this, you
simply configure the link to use all data packet types, then the baseband automatically
picks the best packet type for the current link quality. (This is done using Channel
Quality Driven Data Rate [CQDDR]—for more details, see Chapter 1).

If you choose to use SCO links for your application, you should now have a good feel
for how to select an audio packet type (HV1, HV2, or HV3). Basebands that support the

7
DV packet type will automatically use it when an HV1 link is in use and there is user
data to send.

Now that we understand how Bluetooth wireless technology transmits audio, let's
examine the interfaces by which the audio signal gets into the Bluetooth subsystem.

Using the Palm OS for Bluetooth Applications

In Bluetooth Application Developer's Guide, 2002

The Future of Palm OS Bluetooth Support

In the near future, Bluetooth technology will address the issues of Layer 3
(Network level) support in the Bluetooth communication protocol stack. New
specifications will define a network layer for communications between all the
members of a piconet (not just master to slave), as well as inter-piconet
communication issues.

Roaming and scatternets will also be addressed.

The eventual goal is the creation of true ad-hoc networks, self-configuring

network groupings that grow and change as the user's environment changes.

New editions of the Palm OS Bluetooth Library will expand the Palm OS's
Bluetooth capabilities without compromising existing applications.

Exploring the Foundations of Bluetooth

In Bluetooth Application Developer's Guide, 2002

Paging and Page Scanning

To create a connection between Bluetooth devices one device pages another device,
which must be in Page Scan to respond. The terms “create connection” and “page” are
often used interchangeably although the latter is more specific since connections can
also be created between upper stack layers. A successful page results in an ACL
connection between the paging device, which, by default, becomes the master, and the
paged device, the slave.

To allow an incoming connection, a device must be placed in Page Scan mode. This is
similar to Inquiry Scan in that the mode must be configured, using the
HCI_Write_Page_Scan_Activity, HCI_Write_Page_Scan_Mode, and
HCI_Write_Page_Scan_Period_Mode, and then activated using the same
HCI_Write_Scan_Enable command that controls the Inquiry Scan operation. Provided
both modes have been configured with timing that allows it (see the following), a device
can be in both Inquiry and Page Scan modes at the same time.

HCI_Write_Page_Scan_Activity sets the page scan period and the interval between
scans, and hence the duty cycle. HCI_Write_Page_Scan_Mode determines if the device

8
scans using the mandatory paging scheme or an optional one. Only one optional scheme
is currently defined, although there is a provision for three. It is defined in Appendix
VII of the Core Specification and trades an increased level of complexity and a higher
duty cycle at the paging device for a lower duty cycle at the Page Scanning device. Few,
if any, hardware vendors currently support the optional paging scheme, so a method
must exist for hardware that doesn't support it to connect to hardware that does. For this
reason, devices in both Page and Inquiry Scan that receive an incoming inquiry must
then use the mandatory paging scheme for Tmandatory_pscan seconds following.
HCI_Write_Page_Scan_Period_Mode sets the number of seconds according to the Page
Scan mode (see Table 2.2).

Table 2.2. Relationship between SP Mode and Mandatory Page Scan Period

Scan Period Mode Tmandatory_pscan

P0 >20 seconds
P1 >40 seconds
P2 >60 seconds

To initiate a page, an application issues an HCI_Create_Connection command that

contains the following parameters:

BD_ADDR The Bluetooth device address of the device you wish to page.

Packet_Type The types of ACL packet the local device will support on this link
(i.e. DH/M 1/3/5).

Page_Scan_Repetition_Mode How often the target device enters Page Scan

mode.

Page_Scan_Mode Whether to use the mandatory Page Scan mode, or an

optional mode.

Clock_Offset The estimated difference between the local device's clock and the
target device's clock.

Allow_Role_Switch Determines whether the local device will accept a request

from the target device to swap master/slave roles.

9
Apart from Packet_Type, the first five parameters are provided as part of an inquiry
response. The BD_ADDR is required to identify the target device. The two Page_Scan
parameters determine the exact baseband operation during the page. Knowing the
Clock_Offset of a device is not essential to making a connection—it can still be made if
this value is completely wrong—but the better the estimate, the shorter the connection
time. The paging device uses the BD_ADDR and Clock_Offset parameters to calculate
the frequency the target device will be page scanning on and starts its paging
transmission there. If initially unsuccessful, the paging device then tries other,
progressively less-likely frequencies until eventually all possibilities have been covered.

When the target device receives an incoming page, it does not necessarily accept it
immediately. The HCI_Set_Event_Filter command can be used to switch between three
possible behaviors:

Send an HCI_Connection_Request event to the host and wait for an

HCI_Accept_Connection_Request or an HCI_Reject_Connection_Request
command.

Accept the Page automatically.

Accept the Page automatically only if the paging device accepts master/slave
role switch.

The last is important for profiles such as LAN access where an access point is
discoverable and connectable while being a master of a piconet. A new device, when it
connects, becomes, by definition, the master. The new device must allow the role switch
so that the access point can become a master again and continue to maintain
communications with the existing slaves.

Developing & Deploying …

Masters, Slaves, Role Switches, and Scatternets

10
To upper stack layers, the only difference between a master and a slave is that a master
can talk to several slaves in a piconet, while a slave can only talk to the master of the
piconet.

For some devices, this relationship is important. Take, for example, a PC with a
Bluetooth mouse and keyboard already operating. The PC may also wish to allow a
PDA to connect and synchronize. Since the PDA initiates the connection, it becomes the
master of the new piconet, but the PC will only have allowed this connection if, as part
of the connection request, the PDA stated it allows master/slave role switches. As soon
as the connection is established at baseband level, the PC requests a switch. If the PDA
does not grant it, the PC drops the connection.

Interestingly, for the time between the connection completing and the role switch taking
place, the PC is still master of its old piconet even though it's a slave of the PDA's
piconet. When a single device is a master of one piconet, and slave of another
simultaneously, this is, by definition, a scatternet.

Several manufacturers now support the limited form of scatternet required for a
master/slave role switch while master of an existing piconet, but maintaining the
scatternet for any length of time is still problematic. The Bluetooth specification gives
no way for a slave to demand hold, sniff, or park modes from a master; they must
always be requested. The master is entitled to refuse such requests, so it is impossible to
guarantee that a slave in one piconet will be granted the time required to participate in
another piconet as a master or a slave. Even if devices choose to simply switch between
piconets as they see fit, ignoring the normal request procedures, there are still problems
with how to time these switches in order to maintain multiple connections.

The master of each piconet must periodically poll all its slaves in order to give them an
opportunity to transmit (since slaves only transmit data in response to a master
transmission). How to cope with the variability of the interval between poll
transmissions from a master is particularly awkward. It is possible to devise solutions to
these problems, but there are a number of possible solutions and no guarantee that two
implementers will choose the same one. A single chip set vendor may be able to
demonstrate scatternet operation provided they produce all devices in the scatternet, but
this provision goes against the fundamental Bluetooth concept of interoperability. Work
is progressing in the Bluetooth SIG to devise a standard solution to these problems.

There is an even greater problem with SCO connections in a scatternet, however. The
reserved slots for SCO connection in two scatternetconnected piconets are running on
different clocks. They will eventually drift, relative to each other, so that the reserved
slots coincide, making it impossible for a single device to be part of both piconets.
There is no way to renegotiate the SCO timing once the link has been set up.

Fortunately, the problems with ACL scatternets may be resolved soon, but those of SCO
scatternets will likely be around for a very long time. For the moment though, no
profiles use, let alone require, scatternet operation.

If the page is successful, an HCI_Connection_Complete event is generated at both ends

of the new link with a “Success” status and other parameters describing the connection.
This includes the Connection Handle that, for a master with multiple slaves, is used to

11
route data. A page can fail because it times out or is actively rejected in which case the
paging device generates an HCI_Connection_Complete event with the appropriate
“Failure” status parameter.

Feeling Bluetooth
Paul Braeckel, in Advances in Computers, 2011

1.6 Network Topology

The classification for a BT network is a PAN, which is a person- or device-centric

network of computing devices that are within close proximity, usually a few meters, of
the central person or device. These BT PAN are often mobile environments. Whereas
Wired PAN are physically connected via a cabling medium such as USB or FireWire,
Wireless PAN (WPAN) using BT wireless technology communication via a RF medium
as discussed previously. The topologies21 associated with a BT WPAN are Piconets and
Scatternets. A Piconet22 is an ad hoc, master/slave, wireless computing network that
contains from two to eight devices, one of these devices being the master and the
remaining the slaves. A Scatternet23 collectively groups 2–10 piconets that are within
PAN range of each other and allows communication between the groups of piconets.
The individual devices that are members of a piconet fall into one of seven possible
operational states: Standby, Inquiry, Page, Connected, Sniff, Park, and Hold.

The piconet is the basic network building block associated with BT WPAN. The wired
limitations associated with a fixed network infrastructure do not limit wireless devices.
This mobility and the ad hoc nature of WPAN allow a network to be continuously
changing. As a result, mobile devices are able to migrate in and out of each other's
visible range. The two to eight devices that form a piconet are active devices. One may
generalize the interaction between these devices into three possible configurations:
point-to-point, point-to-multiple, or single-cell, multicell. Figure 2 depicts examples of
these possible device configurations. Within each of these configurations, the piconet
follows a master/slave communication protocol, and, since every BT chip is able to send
and receive RF, every device is able to be either a master or a slave. The point-to-point
configuration is between two devices: one master device and one slave device. The
point-to-multiple or single-cell configuration is between two and eight devices: one
master and two or more slaves. The multicell configuration is between two or more
piconets, which would allow for up to 80 active devices.

Sign in to download full-size image

12
Fig. 2. Piconet topology.

The piconet's master, which is the device that initiates the connection, is responsible for
establishing the links between itself and each of the slaves. It is also responsible for
synchronizing communications while a slave is part of its piconet. All devices in the
established piconet share this physical BT channel, which is the most basic layer in the
BT architecture and serves as the means of device synchronization. This physical
channel is a combination of a frequency-hopping pattern, a slot time increment, and an
access code.24 The frequency-hopping pattern is an index of RF channels that
cumulatively add up to a BT channel. This means, as the name suggests, that a device
hops in a set sequence over all the bands within the ISM band, spending a set amount of
time on each band before hopping to the next band in the index. Section 1.5 discusses
the slot time increment and Section 1.8 discusses the access code.

The process of synchronizing to a frequency-hopping pattern may be divided into two

steps: creation of the RF channel index (Fig. 3) and synchronization of internal clocks
(Fig. 4). To create the RF channel index, the master device uses as input its Bluetooth
Device ID (BD_ADDR25) and internal clock. The BD_ADDR is a 48-bit IEEE standard
address assigned to the device by its manufacturer, registered to the IEEE Registration
Authority, and unique to all BT devices. The internal clock, also known as the device's
native clock, is a 28-bit value based on the system to which it is a part. The output of
this step is an index of RF channels, which is then mapped onto the ISM RF
frequencies. There are slight variations in the derivation of this hopping sequences
based, but Fig. 3 depicts the general case. Additional detail is beyond the scope of this
chapter but may be referenced in the BT specification provided by the BT SIG. To
synchronize internal clocks, each device calculates the offset of its own clock to that of
the master device's clock. Each device then schedules its piconet activities, such as
transmitting and receiving communications, to this synchronized clock. The design
intention in using the master device's ID and clock is to create a pseudorandom BT
channel since theoretically every device will have both a unique device ID and a unique
native clock. When a master device connects with a slave device, the slave device
synchronizes to the master's BT channel, and each device communicates at established
time slots.

Sign in to download full-size image

Fig. 3. Channel-hopping sequence selection. (Bluetooth Special Interest Group,

Specification of the Bluetooth System (11/4/2004): Part B, 83.)

13
Sign in to download full-size image

Fig. 4. Piconet clock synchronization. (Bluetooth Special Interest Group, Specification

of the Bluetooth System (November 4, 2004): Part B, 72.)

What happens when several piconets inhabit the same physical space? Numerous
piconets may exist in the same physical space because they will possess different
physical channels. If two devices were able to create the same physical channel, there
would be constant communication conflicts. This is theoretically not possible, as the
physical channel is based on the master device's ID and internal clock, both of which
are unique to the device. There may however be collisions between BT channels
hopping to the same frequency within the ISM band. The solution to this situation is the
access code that precedes all piconet communications; Section 1.8 details this access
code and the communications packet format. The use of scatternets allows BT devices
to increase the number of networked devices within a given area, overcoming the
maximum number of devices limitation of a piconet. Note however that multiple
piconets do not have to interact to classify as a scatternet even though they may share
the same coverage area. They each would have their own timing and frequency-hopping
algorithm.

A device may be in one of seven possible states when it is part of a piconet. These are as
operational states. These states facilitate the networking of BT devices and allow the
devices to conserve power. Since power management is a concern for mobile devices,
each of these states allows a device to minimize its power usage by only performing
tasks relevant to that particular operational state. Figure 5 depicts theses states and the
transitions that a device may take while interacting with a piconet. Four of the
operational states correspond to a device creating a link to a piconet: standby, inquiry,
page, and connected. A device is in a standby state if it is not associated with a piconet.
A standby device consumes very low power, using only enough to maintain its native
clock. This is the starting state for all devices; it is a waiting state, and the most
common operational state for a BT device to be. A device is in an inquire state when it
is searching for other BT enables devices within PAN range. This inquiry process is an
iterative process whereby a device's radio broadcasts an inquiry request and waits for
responses from other devices within range. If there are other devices within range, they
will respond to the device inquiry with specialized communications called a frequency-
hopping synchronization (FHS) packet, which contains information necessary to
synchronize to the same BT channel. This packet is a variation of the packet format
discussed in Section 1.8. This broadcasting inquiry may result in communication
collisions if more than one device is within range, but after an iterative query process,
the master device will have the BT device address and clock of all devices within range.
A device is in a page state when a master sends out a request for the device to join its
piconet and it is transitioning to a connected state. The page state is a transitional state
that follows the inquiry state, once a master device has determined that a device is

14
present, it pages the device to join the piconet. A device is in a connected state if it is
actively associated with a piconet. Once it establishes a link between itself and a slave,
and the master device assigns an Active Member Address (AM_ADDR, 3 bits) to the
slave device. As long as a device has an AM_ADDR, it is active to the master device
and is a member of the piconet. During this time, the connective device is actively
listening, receiving, and transmitting to its piconet's network traffic. In a piconet
topology, devices are dependent on each other to relay messages, and network traffic.

Sign in to download full-size image

Fig. 5. Piconet operational states. The values shown with each state are the average
power consumption for a device while in that particular state. For comparison purposes,
the power consumption shown for a device in the Standby state is 3% of that used by a
mobile phone.

The remaining three operation states correspond to a device after it has created a link to
a piconet: sniff, hold, and park. A device is in a sniff state when it has an active
connection to a piconet but in a reduced power state and listening to piconet network
traffic at a master-assigned minimal rate of time. This rate of time correlates with
ignoring network traffic for a certain number of time slots. A device is in a hold state
when it has an active connection to a piconet but in a reduced power state. The hold-
state device retains its synchronization with the master as well as its AM_ADDR, but is
only able to listen to Synchronous Connection-Oriented (SCO) link packet transmission
and able to return to PAN participate very quickly, within a 2-ms time frame. While in
the hold state, the device may participate in or initiate the creation of other piconets. A
device is in a park-state when it is not participating in piconet traffic, but it retains clock
synchronization with the master device. The park-state device exchanges its
AM_ADDR for a Parked Member Address (PM_ADDR, 8 bits) address, but it is able to
return to PAN participate very quickly, within a 2-ms time frame. Placing a device in a
park-state allows a piconet to overcome its eight active member limitation. The 8-bit
PM_ADDR allows a master device to park up to 255 slave devices, all of which may
return to active states when needed.

15
How do these states benefit the average BT user? The wireless networking
infrastructure creation is dynamically and automatically performed when BT-enabled
devices are within range of the BT PAN. The devices automatically also share their
capability details when with range. The power management conserves a device's battery
life to achieve the low-power design goal.

Wireless Communications
Michele Zorzi, A. Chockalingam, in Encyclopedia of Physical Science and Technology
(Third Edition), 2003

III.B Personal Area Networks

Recently, wireless technologies for short-range, indoor communications among devices

have been fast emerging with the aim to provide device mobility and system flexibility
by replacing many proprietary cables that connect devices to one another. Widely
referred to as personal area networks, examples of such technologies include Bluetooth
and HomeRF.

Bluetooth is a short-range (≤10 m), low-power (1–100 mW) technology which operates
in the unlicensed 2.4 GHz ISM band. Since microwave ovens, WLANs, etc., can
operate in the same band, in order to avoid interference to/from such sources, Bluetooth
system has been designed based on FH-SS and TDD. The system uses 79 carrier
frequencies over 1 MHz bandwidth. The nominal bit rate of transmission is 1 Mbps.
Bluetooth allows a collection of devices to form small overlapping networks (known as
‘piconets’) in an adhoc fashion. Devices such as PDAs, cellphones, laptops, desktops,
etc., can be part of a Bluetooth system.

The unit that establishes and coordinates a piconet is called the “master.” All other
participants are called the “slaves.” There can be a maximum of seven slaves in a
piconet. Time is divided into slots of 625 μs. The timing is maintained by the master
and slaves synchronize to the master's clock. A FH channel is associated with every
piconet and each piconet has a unique hopping sequence determined by the master. The
frequency hopping rate is 1600 hops/sec. A collection of piconets is called a
“scatternet.”

Higher layer packets are fragmented into Bluetooth physical layer packets. Each packet
has 126 bits of control information and a maximum payload of 2745 bits. Packet
transmissions on one hop frequency can take multiple slots. Full duplex communication
is realized through TDD. Access control is exercised by the master. Only
communication between the master and a slave is possible (i.e., slave-to-slave
communication is routed via the master). The master transmits in the odd-numbered slot
and the corresponding slave responds in the next slot.

It is likely that the Bluetooth specification will be adopted in the IEEE 802.15 Wireless
Personal Area Network standard.

HomeRF is another short-range, low-power wireless technology which will enable a

class of mobile consumer devices drawing from the content of the Internet and home

16
PC. HomeRF technology is supported by an industry association of several computer,
telecom, and consumer electronics companies. The origins of HomeRF are from the
IEEE 802.11 WLAN standard and the DECT system. IEEE 802.11 uses CSMA/CA for
multiple access and is good for data. DECT, on the other hand, uses TDMA for multiple
access and is good for voice. HomeRF essentially attempts to combine the best features
of both IEEE 802.11 and DECT in order to provide data and voice communications
through mobile consumer devices. Accordingly, the Shared Wireless Access Protocol
(SWAP) has been developed as an open standard for voice and data networking. SWAP
handles voice like DECT but using frequency hopping. SWAP handles data like IEEE
802.11 but uses relaxed PHY layer specifications to reduce the cost of the mobile
device.

Related terms:
 Internet of Things
 Media Access Control
 Bluetooth Low Energy
 Special Interest Group
 Wi-Fi
 Bluetooth Device
 Channel Assignment
 Service Discovery
 zigbee
 wireless local area network

View all Topics

Recommended publications

Computer Communications

Journal

Ad Hoc Networks

Journal

17
 

Computer Networks

Journal

Bluetooth Application Developer's Guide

Book • 2002

[Link]
system-using-spartan3an-fpga-starter-kit

[Link]

18