Learning Center
Plans & pricing Sign in
Sign Out



									    Design and implementation of a Bluetooth
              based Kiosk system

                    Mid Semester Report

      Tsachi Nissim   033072281
      Yahav Bar yosef 033968553

Supervisor : Nir Naaman
                                           Table of contents

1. Introduction......................................................................................................3
   1.1. Project objectives ......................................................................................................... 3
   1.2. Motivation..................................................................................................................... 3
   1.3. What is PIKS? .............................................................................................................. 3
   1.4. Solution and Implementation...................................................................................... 3
2.The Characteristics of the PIKS system...........................................................4
3.Using Bluetooth as a mean of communication .............................................11
4.Bluetooth: Theory ...........................................................................................11
   4.1 The Bluetooth air interface. ....................................................................................... 12
   4.2 Networking. ................................................................................................................. 13
     4.2.1 Paging .................................................................................................................... 15
     4.2.2 Inquiry.................................................................................................................... 15
     4.2.3 Connection state..................................................................................................... 16 Active mode..................................................................................................... 16 Sniff mode........................................................................................................ 16 Hold mode....................................................................................................... 16 Park mode ....................................................................................................... 17
     4.2.4 Scatternet................................................................................................................ 17

9. References 18

1. Introduction.

 1.1. Project objectives

 The project objectives are:
       design a Bluetooth based PIKS on a wireless network of PDA’s, and then implement
       it using Compaq iPaq 3870 with integrated Bluetooth and point to multipoint
       Bluetooth devices.
       Design and implement a simple PIKS application which will run on the PDA units
       and another application which will run on the server.

 1.2. Motivation
There are many places were the need to quick and focused information emerges, and you
don't always have time to stand in lines or go and look for the info center.
Examples for these places are malls, airports, universities, companies, theme parks and so on.
Imagine yourself in the airport: You have just arrived, and you need to catch your flight.
Instead of standing in lines you take out your PDA and in several seconds, using the PIKS
system, you get the exact time of your departure, the departure gate and you are all set to go.

 1.3. What is PIKS?

PIKS stands for Personal Information Kiosk System.The objective of PIKS is to provide a
wide range of information and services to people who are mobile within a defined
organizational area. PIKS builds upon the future availability of small. Simple PDA-type
devices that will be carried by everyone and used for a variety of purposes. While using a
wireless connection, a user can retrieve information relevant to him in real-time. This
information can even be adapted to the user’s current location.
 PIKS can be deployed at a wide variety of places, such as airports, theme parks, malls,
hospitals, museums, or any other large campus where visitors or workers need immediate
access to sources of information that will enable them to easily get what they need. The
PIKS application model is designed to allow any type of PDA with limited resources to
interact with PIKS. The data and application are located on a central server, while a small
generic kernel on the PDA supports user interaction. The idea is to keep a minimal network
messaging, a low cost PDA device, and a reasonable response time.

 1.4. Solution and Implementation
We will design a network built up from PDA units integrated with Bluetooth chips which
will demonstrate the use of PDA units in a PIKS environment, and point to multipoint
Bluetooth units which will act as the access points.
The PIKS system will be constructed out of PDA units running the client application and
access points running the server application.

2. The Characteristics of the PIKS system


PIKS is a full end-to-end architecture and implementation to support access to organizational
information for mobile users over a wireless link. It is based on a technology called MAP
(Mobile Application Partitioning) which provides an optimal way of splitting an application
between a desktop server and a semi-intelligent PDA. The application functionality is
defined and run at the server, while the mobile device runs a small program that handles the
rendering and control of the user interface.

 The PIKS system is built to supply a certain service to the public. Therefore, there are some
requirements that must be met:
        The design must keep in mind the fact that the system is about to be used by
       thousands of novice users in an unfamiliar environment. Therefore, the interface must
       be simple.
        Power conservation is another point that should be dealt with, due to the fact that
       users in the mass market expect their appliances to work weeks or even months
       without battery replacement.
       Small size – small size is very important in order to encourage the average user to use
       the application in everyday life.
       Transparent connection: a totally transparent connection with zero configuration by
       the user is required.
       Low cost: to encourage the mass use.
       Serve many users: MASS market.

In addition to information access, PIKS provides the following services:
    User physical location within the organization site is made known to the server
framework - can be used e.g. to provide location-specific information.
    Information push service allows for broadcast of announcements or commercial
    Instant messaging service lets users communicate by exchange of short text messages.
Can also be used by a user to contact a site help center.

PIKS Infrastructure

The following illustration demonstrates the infrastructure of the PIKS:

                                                  SQL                      Legacy DB


                  Static Data   :            Dynamic& Personal Data:
                  XML Kiosk                  Java appl. module (Pikslet)
                                LDDI                                              Supervisor

              Wireless              Wireless                Wireless

               PDA                     PDA                    PDA

Wireless PDA: A handheld device with wireless communication hardware, running a thin
client program responsible for interaction with server and for user interface display and
control. Most of the application logics, including layout management of screen graphics, is
done at the server side, leaving the client only the basic tasks of presenting the screens to user
and sending the user input back to the server. Keeping the client small will allow us to use
the emerging class of card-sized handheld devices as the primary platform for PIKS client
Wireless Network: Consists, basically, of a number of access points uniformly distributed at
the site. Each access point communicates with wireless mobile handheld devices currently
located within its reach range, and forwards the communication to the PIKS server. The
mobile device roams between access points as the user walks, and the server is aware of
current user location according to the access point currently handling the device.

Server: Server functionality is split between three components: SKCM-LDDI, GDDI and
Supervisor. Each one is a Java program, hence not limited to a specific server platform.

SKCM - Server Kiosk Controller Manager is responsible for management of network
connection with mobile users (data communication and physical location identification), and
for linking the user to PIKS Server and applications.

LDDI - Local Dynamic Data Interface, is the layer where the applications are loaded and run.
Two application types are available: XML Kiosks for static data and Java application
modules (called Pikslet - stands for PIKS and servlet) for dynamic and/or personal data.

           XML Kiosk(s) loads the information, to be presented to mobile users, from an
       XML file and uses a PIKS specific DTD that defines content, layout and flow.
       The kiosks are loaded at the server startup time. Due to this fact, and to the rigid
       structure of XML documents, only static data (with some limited dynamic
       extensions) can be viewed using this type of application (hence the name

           Pikslet(s) is a Java application module capable of dynamic interaction with
       users and creation of content based upon user input. Since it does not run as a
       stand-alone process but rather is loaded and executed within the server
       framework, we call it similar to “servlet”. Basically, Pikslets are arbitrary Java
       programs (classes), so any required functionality can be implemented. The
       provided API set allows a developer to incorporate the program into PIKS
       framework and make it interact with mobile users.

GDDI - Global Dynamic Data Interface, is a predefined PIKS service intended to
periodically bring information from different information sources, like an organizational
legacy database sitting on the LAN, or external web server reached via the Internet. GDDI
pushes the obtained information down to LDDI environment and makes it available to
interested Pikslets or XML Kiosks.

Supervisor - is an administration tool helping the system manager to monitor the server,
network and mobile user activity. It can also be used to gather statistical information on user
(customer) behavior.

The thin client program, running on the handheld device, is written in Java-like language
called Waba (see WabaVM (virtual machine) is currently supported on
the following platforms: PalmOS, WinCE and PocketPC. Any device running them can run
the PIKS client program. As for wireless communication hardware, any system capable of
providing TCP/IP or serial port communication between such devices and a desktop (NT,
Unix etc) station can be used.
The thin client program uses standard serial or TCP/IP network layers provided by the OS,
assuming that the wireless modems implement the underlying physical network stack.

Upon communication establishment with the server, a handshake procedure is performed
first, during which the client receives a temporary address from the server which will be used
to identify the client during the given network session. User information (like user full name,
user id, native language etc), stored locally at the client, will be sent to the server and used
for example to retrieve the user profile stored at the organization server, or to use the
specified language for communication when possible etc. An anonymous guest user can also
access the system and receive generally available open information.

The server sends to clients bytecode messages which describe a full screen of widgets
(typically a few hundred bytes long). The client parses the message and displays the
information (wrapped in information widgets like text or bitmap widgets) and user input
widgets (like buttons or text entry keypad widgets). User input (button activation events, or

typed text) - typically a few dozen bytes long message, is sent back up to the server for
processing. Then the server returns a new message containing the next screen, and so on.

3 Applications

On the other edge of the system, application layer implements the required business logics.

3.1 Pikslets

Pikslets, or java application modules, are .class files that are loaded into server during the
start-up. A pikslet is an Java class that extends our Pikslet class and implements a number of
obligatory methods. The Pikslet class and other PIKS API are provided in and packages, contained in the PIKS
installation (piks.jar file). A pikslet developer uses arbitrary Java features to program the
desired application functionality (e.g. JDBC for database access), and uses PIKS API to
present the application user interface to the remote user. The API set was designed to
resemble standard graphic user interfaces like Java AWT or Swing API, so a developer
familiar with these interfaces will find PIKS development environment to be similar.
Additionally, PIKS API includes methods for querying the user-specific information (name,
current location), and methods for message exchange between mobile users or between users
and external desktop applications.

The graphic object set (widgets) includes Labels, Buttons, CheckBoxes, RadioButtons, Text,
Bitmap Images, Tables, TextEntries, KeyPads, HotSpots, DrawAreas (for presenting simple
graphic objects like Lines and Rectangles). Naturally, the PIKS graphics, intended for
palmtop devices, features only a subset of graphic capabilities of e.g. Swing or other tools for
desktop computer displays.

3.2 XML Kiosks

PIKS has an entirely independent mode of application development. An application
consisting of a fixed set of screens containing static data, and predefined flow rules between
them, can be written as an XML document, according to PIKS DTD. Basically, the XML
document (a kiosk) contains elements describing list of screens, widget composition of each
screen and flow rules relevant for activation of buttons and other active objects.


GDDI is an optional mechanism for periodic information fetching from data sources external
to PIKS. It has a set of hunters each capable of accessing a different data source. For
example, the web hunter can bring in a page from a web server, dB hunter can bring
information from a database table. Hunters are configured by a different XML file
(GDDI.xml) that specifies - for each hunter - the time period of information fetching and

exact information location (URL in case of web hunter, DB server, user, table specification
with an SQL query in case of dB hunter etc). A special interface exists that lets GDDI push
the brought data into XML kiosks or Pikslets that subscribed to it. This mechanism can be
handy when such a common task like periodic data retrieval from well known data sources
must be performed by the application.


From the PIKS server’s viewpoint, most of the initiatives that cause screen transitions are
originated by the user (mainly tapping abutton) – and thus are reffered to as “PULL”
paradigm. However, to provide a way of asynchronously “PUSH” some content to the user –
e.g. Alert messages, we provide the PMAIL (PIKS mail system) package together with a set
of APIs that enable the Pikslet developer query/get/delete “mail” messages and present them
to the user as part of the screen flow.

Designing the PIKS network and applications

The design of the PIKS network

The PIKS network will consist of two main units:
A PC connected to a point to multipoint Bluetooth device, and several Bluetooth integrated
PDA devices. The PC will act as the server and an access point (usually these roles are

separated to a computer acting as a server and an access point connected to this computer,
either physically or wirelessly) - to which the PDA devices will connect to perform a
communication cell. The PC will run the server application – the SKCM, and will get
connections from the PDA's who will run the client application. We will examine some
features of this communication cell: connections and hang-offs, response time of the server
and other services offered by the PIKS system which are mentioned above.

Choosing the protocol

There are several ways to connect wirelessly between the wireless units and the access point
The protocol that was choused for the first checks is TCP/IP due to the fact that it provides a
reliable connection and will let us deal with the network design and building at first, without
warring about the communication itself.
The idea is to try and build a more low leveled connection in the future. This will help
making a power conserving connection, which will be able to run on very small,
unsophisticated devices with long battery life. Of course, this will be done after a profound
basis of understanding of the subject will be achieved by using TCP/IP.

Writing a PIKS application: The Server

In this project we intend to put our efforts in designing and building of a true Bluetooth based
PIKS. The server uses a XML file which is loaded on server startup, and all the static
information is stored there. The XML file should be written according to exact specifications
which are all specified in another file called a DTD file. The information is parted into
screens – each screen represents a screen that will be sent to the PDA on demand.
 Dynamic information (information that can change while the client is connected to the
server) is provided using JAVA application which can interact with the client upon request.
At first we will deal with the case of static information – just to simple the tests.

Writing a PIKS application: The Client

The client application, as mentioned before, must be simple and not consume a lot of
memory. The client will run an application which will connect to the server, ask for some
information, and display it on the PDA screen. The client code is written in Waba and is
loaded to the PDA only once. Then, whenever a person activates the client application within
a region that provides PIKS service, he will receive a welcome screen which will introduce
before him all the options and information he can get.

Tests and simulations


In order to perform the first checks we used a PDA emulator running on a PC. This emulator
can run the client application and act very similarly to the real PDA. At first, the client
application must be loaded to the emulator as in real life. This is followed by setup of the

communication – at first we used loopback ( and run both server and client on the
same machine.
Then, we used two machines- one running the server application and the other running the
client application. This was done using TCP/IP, in the computer network lab.
The next step is to run the application using Bluetooth devices as means of communication –
although in this stage the communication protocol is still TCP/IP.

Running both server and client on the same machine – using PDA emulator.

We started by writing a XML file which will demonstrate the information that could be in a
PIKS system located in the computer networks lab. The information was separated into
screens, each screen has it own topic:

for example: Service, which includes all the information required to contact the labs' service
and a map of the lab. A click on the Service button will ask for the proper screen from the
server and will result in this screen:

a click on the Map button will result in the following screen, which is a map of the computer
networks lab:

after numerous tests we concluded that the demo system is ready to the next checks.

running server and client on separate machines – using TCP/IP communication


Using Bluetooth communication


3. Using Bluetooth as a mean of communication
Several wireless technologies can be used for PIKS implementation, including IEEE 802.11
wireless LAN and Mobile telephone system, but it seems that Bluetooth answers most of the
important requirements. However there are several problems that must be dealt with while
using a Bluetooth based implementation:
        Long synchronization time.
        Power consumption during roaming due to search and reconnecting.
These problems are hard to be avoided from but a smart design can lower their effect.

 4. Bluetooth : Theory
 This chapter is a brief summery of the main points of the Bluetooth technology, that are
relevant to our project. For more details refer to the official Bluetooth spec ( reference 1).

 BlueTooth is a universal radio interface in the 2.45 GHz frequency band that enables mobile
devices to connect and communicate wirelessly via short-range networks. Each unit can
communicate with up to 7 other units per piconet. Two or more units sharing the same
channel form a piconet. Each unit can belong to several piconets at the same time. In each
piconet one unit acts as a master, and the others are his slaves. All communication in the
piconet is defined and managed by the master unit.

 4.1 The Bluetooth air interface.

 The bluetooth system uses the ISM (Industrial-Scientific-Medical) band, which is open to
everyone, and ranges from 2.4 GHz to 2483.5 MHz in the US and Europe, (only parts of
these bands available in France and Spain), and from 2.471 GHz to 2.487 GHz in Japan. This
way we can use the technology worldwide, if the transceivers can select the proper segment
in the band.
 Since the ISM band is open to anyone, there may be some interference to transmissions. In
order to overcome this problem and provide a more reliable connection a frequency-hop
spectrum-spreading technique is used, where the frequency band is divided into several hop
channels. During a connection, the bluetooth units hop from one channel to another in a
pseudo-random fashion.
 This way, if a frequency is jammed, the data will be lost (unless it can be corrected using
FEC), but it will be retransmitted again at a different frequency hops.
 Bluetooth channels use a FH/TDD scheme. The channel is divided into 625 microseconds
intervals – which are called time slots. A different hop frequency is used for each slot
according to frequency hopping sequence of the piconet. The sequence is determined by
piconet masters’ device address and his clock. One packet can be transmitted per slot.
Subsequent slots are alternately used for transmitting and receiving. A slave may transmit to
the master only if he was addressed in the previous slot.

Figure 1: Master – Slave communication.

 In each slot a packet can be exchanged between the master and one of the slaves.
Each packet begins with a 72-bit channel access code that is derived from the master identity
and is unique for each channel. The access code is used for identification, synchronization
and compensating for clock offset. A header trails the access code. It contains important
control information, such as MAC address, packet type etc. the header has a fixed size of 54
bits. A payload may or may not trail the header, and its length may vary from 0 to 2745 bits.

Furthermore, multi-slotted packets are used to support high data rates (a packet can cover 1,
3 or 5 slots). The channel does not change during a multi-slotted packet.
 There are two different link types defined in the bluetooth standard:
     1. SCO - synchronous connection-oriented link. It’s a symmetric, point to point link
         that reserves slots and therefore can be considered as a circuit switched connection.
         The master sends SCO packets at regular intervals and the slave is always allowed to
         respond in the following slot.
     2. ACL - asynchronous connectionless link. ACL links support symmetrical or
         asymmetrical, packet-switched, point-to-multipoint connections typically used for
         bursty data transmission. Master units use a polling scheme to control ACL

The following diagram shows mixed SCO and ACL links on a piconet with one master and
two slaves. Slave 1 supports an ACL link and an SCO link with a six-slot SCO interval.
Slave 2 only supports an ACL link. Note: slots may be empty when no data is available.

Figure 2: ACL and SCO links.

 As it was mentioned before, the Bluetooth radio operates in an open band that is subject to
considerable uncontrolled interference. Thus, the air interface has been optimized to deal
with interference:
   • Frequency hopping techniques are applied with a high hopping rate and short packet
        lengths (1,600 hops/s for single-slot packets). If a packet is lost, only a small portion
        of the message is lost.
   • Packets can be protected by forward error control.
   • Data packets are protected by an ARQ scheme in which lost data packets are
        automatically retransmitted.
   • Voice is never retransmitted. Instead, a robust voice-encoding scheme is used. This
        scheme, which is based on continuous variable slope delta (CVSD) modulation,
        follows the audio waveform and is very resistant to bit errors — errors are perceived
        as background noise, which intensifies as bit errors increase.

 4.2 Networking.

 Two or more Bluetooth units that share a channel form a piconet. To regulate traffic on the
channel, one of the participating units becomes a master of the piconet. Any unit can become

a master, but by definition, the unit that establishes the piconet assumes this role. All other
participants are slaves. Participants may change roles if a slave unit wants to take over the
master role. However, only one master may exist in a piconet at any time. Every unit in the
piconet uses the master identity and clock to track the hopping channel. Each unit also has its
own (native), free-running clock. When a connection is established, a clock offset is added to
synchronize the slave clock with the master clock. The native clock is never adjusted,
however, and offsets are solely valid for the duration of the connection. Master units control
all traffic on a channel. They allocate capacity for SCO links by reserving slots. For ACL
links, they use a polling scheme. A slave is only permitted to send in the slave-to-master slot
when it has been addressed by its MAC address in the preceding master-to-slave slot. A
master-to-slave packet implicitly polls the slave; that is, an ordinary traffic packet addressed
to a slave polls the slave automatically. If no information to the slave is available, the master
can use a POLL packet to poll the slave explicitly. POLL packets consist of an access code
and header only. This central polling scheme eliminates collisions between slave

Figure 3: BT unit state machine diagram
 As we can see from the diagram in figure 3, there are two major states: STANDBY and
CONNECTION; in addition, there are seven substates, page, page scan, inquiry, inquiry
scan, master response, slave response, and inquiry response. The substates are interim
states that are used to add new slaves to a piconet.

 4.2.1 Paging
  In order to establish new connections the procedures inquiry and paging are used. The
inquiry procedure enables a unit to discover which units are in range, and what their device
addresses and clocks are. With the paging procedure, an actual connection can be established.
Only the Bluetooth device address is required to set up a connection. Knowledge about the
clock will accelerate the setup procedure. A unit that establishes a connection will carry out a
page procedure and will automatically be the master of the connection.
  In the paging and inquiry procedures, the device access code (DAC) and the inquiry access
code (IAC) are used, respectively. A unit in the page scan or inquiry scan substate
correlates against these respective access codes with a matching correlator.
  For the paging process, several paging schemes can be applied. There is one mandatory
paging scheme, which has to be supported by each Bluetooth device. This mandatory scheme
is used when units meet for the first time, and in case the paging process directly follows the
inquiry process. Two units, once connected using a mandatory paging/scanning scheme, may
agree on an optional paging/scanning scheme.
  In the page scan substate, a unit listens for its own device access code for the duration of
the scan window. During the scan window, the unit listens at a single hop frequency, its
correlator matched to its device access code. The scan window shall be long enough to
completely scan 16 page frequencies.
  When a unit enters the page scan substate, it selects the scan frequency according to the
page hopping sequence corresponding to this unit. This is a 32-hop sequence in which each
hop frequency is unique. Every 1.28s a different frequency is selected.
  The scan interval T page scan is defined as the interval between the beginnings of two
consecutive page scans. A distinction is made between the case where the scan interval is
equal to the scan window (continuous scan), the scan interval is maximal 1.28s, or the scan
interval is maximal 2.56s. These three cases determine the behavior of the paging unit; that
is, whether the paging unit shall use R0, R1 or R2.
  The page substate is used by the master (source) to activate and connect to a slave
(destination), which periodically wakes up in the page scan substate.
  The page procedure in the master consists of a number of steps. First, the slave’s device
address is used to determine the page hopping sequence. For the phase in the sequence, the
master uses an estimate of the slave’s clock. With this estimate the master can predict when
the slave wakes up and on which hop channel.
  The estimate of the Bluetooth clock in the slave can be completely wrong. Therefore, the
master will send its page message on a number of hop frequencies. It will in fact transmit
also on hop frequencies just before and after the current, predicted hop frequency.
  The master sequentially transmits on two different hop frequencies in each slot. In the
following slot, the receiver will listen to two corresponding hops for ID packet. The hops are
selected according to the page_response hopping sequence. For each page hop there is a
corresponding page_response hop.
  Since the master doesn’t know when the slave will enter the page scan substate, he has to
repeat one train N_page times or until a response is obtained. For R1 the repetition number is
128, for R2 it is 256.

 4.2.2 Inquiry
  In the inquiry scan substate the receiver scans for the inquiry access code long enough to
completely scan for 16 inquiry frequencies. The scan is performed at a single hop frequency.
The inquiry procedure uses 32 dedicated inquiry hop frequencies according to the inquiry

hopping sequence. These frequencies are determined by the general inquiry address. The
phase is determined by the native clock of the unit carrying out the inquiry scan; the phase
changes every 1.28s.
  The inquiry substate is used by the unit that wants to discover new devices. The TX and
RX frequencies follow the inquiry hopping sequence and the inquiry response hopping
sequence, and are determined by the general inquiry access code and the native clock of the
discovering device. In between inquiry transmissions, the Bluetooth receiver scans for
inquiry response messages. When found, the entire response packet (which is in fact a FHS
packet) is read, after which the unit continues with the inquiry transmissions. Two 10 ms
trains A and B are defined, splitting the 32 frequencies of the inquiry hopping sequence into
two 16-hop parts. A single train must be repeated for at least N inquiry =256 times before a
new train is used. In order to collect all responses in an error-free environment, at least three
train switches must have taken place. As a result, the inquiry substate may have to last for
10.24 s unless the inquirer collects enough responses and determines to abort the inquiry
substate earlier. If desired, the inquirer can also prolong the inquiry substate to increase the
probability of receiving all responses in an error-prone environment. If an inquiry procedure
is automatically initiated periodically (say a 10 s period every minute), then the interval
between two inquiry instances must be determined randomly. This is done to avoid two
Bluetooth units to synchronize their inquiry procedures.
  When a paging unit and recipient select the same wake-up carrier, the recipient receives the
access code and returns an acknowledgement. The paging unit then sends a packet containing
its identity and its current clock. After the recipient acknowledges this packet, each unit uses
the paging unit’s parameters for hop selection — thereby establishing a piconet in which the
paging unit acts as the master.

 4.2.3 Connection state
 In the CONNECTION state, the connection has been established and packets can be sent
back and forth. In both units, the channel (master) access code and the master Bluetooth
clock are used. The hopping scheme uses the channel hopping sequence.
 The Bluetooth units can be in several modes of operation during the CONNECTION state:
active mode, sniff mode, hold mode, and park mode. Active mode
 In the active mode, the Bluetooth unit actively participates on the channel. The master
schedules the transmission based on traffic demands to and from the different slaves. In
addition, it supports regular transmissions to keep slaves synchronized to the channel. Active
slaves listen in the master-to-slave slots for packets. Sniff mode
 In the sniff mode, the duty cycle of the slave’s listen activity can be reduced. If a slave
participates on an ACL link, it has to listen in every ACL slot to the master traffic. With the
sniff mode, the time slots where the master can start transmission to a specific slave is
reduced; that is, the master can only start transmission in specified time slots. These so-called
sniff slots are spaced regularly with an interval of T_sniff. Hold mode
  During the CONNECTION state, the ACL link to a slave can be put in a hold mode. This
means that the slave temporarily does not support ACL packets on the channel any more
(note: possible SCO links will still be supported). With the hold mode, capacity can be made
free to do other things like scanning, paging, inquiring, or attending another piconet. The unit

in hold mode can also enter a low-power sleep mode. During the hold mode, the slave unit
keeps its active member address (AM_ADDR). Prior to entering the hold mode, master and
slave agree on the time duration the slave remains in the hold mode. A timer is initialized
with the holdTO value. When the timer is expired, the slave will wake up, synchronize to the
traffic on the channel and will wait for further master instructions. Park mode
 When a slave does not need to participate on the piconet channel, but still wants to remain
synchronized to the channel, it can enter the park mode which is a low-power mode with
very little activity in the slave.
 The parked slave wakes up at regular intervals to listen to the channel in order to re-
synchronize and to check for broadcast messages. To support the synchronization and
channel access of the parked slaves, the master supports a beacon channel described in the
next section. The beacon structure is communicated to the slave when it is being parked.
When the beacon structure changes, the parked slaves are updated through broadcast
 In addition for using it for low power consumption, the park mode is used to connect more
than seven slaves to a single master. At any time, only seven slaves can be active. However,
by swapping active and parked slaves in the piconet, the number of slave virtually connected
can be much larger. There is no limitation to the number of slaves that can be parked. To
support parked slaves, the master establishes a beacon channel when one or more slaves are
 The beacon channel serves four purposes:
1. transmission of master-to-slave packets which the parked slaves can use for
2. carrying messages to the parked slaves to change the beacon parameters.
3. carrying general broadcast messages to the parked slaves.
4. unparking of one or more parked slaves.

 4.2.4 Scatternet.
  Multiple piconets may cover the same area. Since each piconet has a different master, the
piconets hop independently, each with their own channel hopping sequence and phase as
determined by the respective master. In addition, the packets carried on the channels are
preceded by different channel access codes as determined by the master device addresses. As
more piconets are added, the probability of collisions increases; a graceful degradation of
performance results as is common in frequency hopping spread spectrum systems. If multiple
piconets cover the same area, a unit can participate in two or more overlaying piconets by
applying time multiplexing. To participate on the proper channel, it should use the associated
master device address and proper clock offset to obtain the correct phase. A Bluetooth unit
can act as a slave in several piconets, but only as a master in a single piconet: since two
piconets with the same master are synchronized and use the same hopping sequence, they are
one and the same piconet. A group of piconets in which connections consists between
different piconets is called a scatternet.
 A master or slave can become a slave in another piconet by being paged by the master of
this other piconet. On the other hand, a unit participating in one piconet can page the master
or slave of another piconet. Since the paging unit always starts out as master, a master-slave
role exchange is required if a slave role is desired.

     9. References

     1. Specification of the Bluetooth System v1.0B (December 1st 1999).


To top