Queuing and QoS
models in
Bluetooth
Presented by:
Mohammad Hosein Yarmand
ECE 731 course
October 2006
1
What is Bluetooth? [1]
2
z
Bluetooth is a standard for short range, low power, low cost
wireless communication that uses radio technology
z
Ericsson joined forces with Intel Corporation, International Business
Machines Corporation (IBM), Nokia Corporation, and Toshiba
Corporation to form the Bluetooth Special Interest Group (SIG) in early
1998
z
The resulting Bluetooth specification is open and freely
available at the official Bluetooth website www.bluetooth.org
Usages
3
z
intelligent devices (PDAs, cell phones, PCs)
z
data peripherals (mice, keyboards, joysticks, cameras, digital
pens, printers, LAN access points)
z
audio peripherals (headsets, speakers, stereo receivers)
z
embedded applications (automobile power locks, grocery
store updates, industrial systems, MIDI musical instruments)
Network configuration
Network configuration of Bluetooth (a) piconet and (b) scatternet
4
Network configuration
5
z
Piconets: a cluster of up to eight Bluetooth devices
z
scatternet: Two piconets can be connected through a common
Bluetooth device (a gateway or bridge) to form a scatternet
z
These enable devices which are not directly communicating
with each other, or which are out of range of another device, to
exchange data through several hops in the scatternet.
Protocol stack
6
Protocol stack (cont)
7
z
The Transport group protocols allow Bluetooth devices to
locate each other, and to manage physical and logical links
with higher layer protocols and applications
z
These protocols support both asynchronous and synchronous
transmission
z
The Application group consists of actual applications that use
Bluetooth links. They can include legacy applications as well as
Bluetooth-aware applications
Protocol stack (cont)
z
z
z
The Middleware Protocol group includes industry-standard
protocols and Bluetooth protocols.
Industry standard : PPP, IP, TCP, WAP, and object exchange
(OBEX) protocols.
Bluetooth :
–
–
–
8
a serial port emulator (RFCOMM) that enables legacy applications
to operate seamlessly over Bluetooth transport protocols,
a packet based telephony control signaling protocol (TCS) for
managing telephony operations, and
a service discovery protocol (SDP) that allows devices to obtain
information about each other’s available services.
Communication
z
- SCO links are characterized by a periodic, single-slot packet
assignment, and are primarily used for voice transmissions
- A device with an ACL link can send variable length packets of
1, 3 or 5 time-slot lengths
z
9
The Bluetooth uses TDD and TDMA for device communication.
A single time slot is 625 μ sec in length. At the Baseband layer,
a packet consists of an access code, a header, and the
payload.
Communication
10
z
Bluetooth uses polling-based packet transmission. All
communication between devices takes place between a master
and a slave, using TDD.
z
The master will poll each active slave to determine if it has data
to transmit. The slave may only transmit data when it has been
polled. Also, it must send its data in the time slot immediately
following the one in which it was polled.
z
The master transmits only in even numbered time slots, while
the slaves transmit only in odd-numbered time slots.
Piconet
11
z
One device holds the role of master, while the rest of the
devices are slaves
z
maximum of seven slaves can be active in a piconet at any
given point in time
z
the rest of the slaves must be “parked.” The maximum number
of “parked” slaves is 255 per piconet
Piconet (cont)
12
z
Any Bluetooth device can function within a piconet as a master,
a slave or a bridge.
z
These roles are temporary and exist only as long as the piconet
itself exists.
z
The master device selects the frequency, the frequencyhopping sequence, the timing (when the hops will actually
occur) and the polling order of the slaves.
z
The master is also responsible for instructing the slave devices
to switch to different device states for periods of inactivity.
Piconet (cont)
13
z
A master and slave must exchange address and clock information in
order for the slave to join the master’s piconet.
z
Bluetooth devices each have a unique Global ID used to create a
hopping pattern.
z
The master radio shares its Global ID and clock offset with each slave
in its piconet, providing the offset into the hopping pattern.
z
A slave must be able to recreate the frequency-hopping sequence of
the piconet it has joined, must know which frequency to use at which
time, and must synchronize itself with the master’s clock.
Piconet (cont)
14
z
A Bluetooth bridge device (or gateway) interconnects two or
more piconets for multi-hop communication.
z
The bridge communicates with all the piconets connected to it
by aligning itself with the clocking of each piconet when it is
ready to communicate.
z
A bridge device may be a slave in all of the piconets to which it
is connected, or it may be a master in one piconet and a slave
in the others.
Device states
15
A queuing model [2]
16
z
We present a queuing model for Bluetooth multipoint
connection systems
z
Assumptions: one piconet or scattemet as the main interest, all
nodes have infinite buffer size, connection setup is assumed to
be established
z
A two-level priority queuing system can maintain QoS services
z
The model is based on a non-preemption priority queue
QoS variables
17
z
Bandwidth: In order to allow applications to run sufficiently and
smoothly over a Bluetooth wireless link, there must exist a
certain amount of bandwidth
z
Delay: Applications that require real time interaction are
sensitive to delay. To minimize the transmission delay, most
applications have some type of "playback“ buffer. If a packet is
lost, than packet retransmission can cause additional delay.
z
The propagation delay is insignificant, and main delay factor is
the queuing delay at the master node
QoS variables
18
z
Delay Variation: The difference between the minimum and the
maximum delay within the system (jitter)
z
Throughput: The maximum amount of data received at some
instant in time for a given traffic load
z
Packet Loss: If the throughput is high and the available
bandwidth is low, then we are going to have loss of packets and
high delay
Bluetooth behavior mapped to QoS
z
One interest is to find out how Bluetooth QoS can support the
four kinds of services
z
These services are described as traffic types:
- continuous stream of data
- VBR data
- data in bursts
- control system data.
z
19
Another interest is to see how the priority queue model affects
the capacity of the Bluetooth system
Proposed priority queue model
20
z
Here a priority queue, of type M/G/1, with one Bluetooth master
acting as the server, and a range of one to seven Bluetooth
slaves
z
The queue type that will be discussed here is the Head-of-theline (HOL) priorities
z
As jobs arrive, they are queued according to their priority
groups. A customer from group p will join the end of the queue
that they belong to and in front of the queue that has a lower
priority, that is from group p-1
Proposed priority queue model (cont)
21
Proposed priority queue model (cont)
z
The utilization
factor:
_
_
ρ P = λP χ P
χ the mean service time
P λ
_
_
p
χ = ∑ χp
p=1 λ
_
_
_
χ = χ1 = χ 2 =
z
22
1
μ
The average delay, or waiting time (denoted by W0 ),
within the system:
Proposed priority queue model (cont)
_
P
W0 = ∑ ρi
i =1
z
χ
2χi
23
P
λi χi2
i =1
2
=∑
the delay time or wait time for a specific priority p:
WP = W0 +
z
_
2
i
_
P
∑
i= p
_
χ i λ iW i +
P
∑
_
χ i λ iW P
i = p +1
we must find the delay time for the queue in which job p for all
jobs with the same Priority and higher Priority, that is p+1 to P
Proposed priority queue model (cont)
z
Since we are using a priority queue with two priorities we are
able to derive
equations for the delay time of each priority
_
_
_
2
λ1 χ 12
λ1 χ 1 + λ 2 χ 22
W2 =
W1 =
2 (1 − ρ 2 )
2 (1 − ρ − ρ )(1 − ρ )
1
z
2
The throughput (β ) = λ * packet size that is to be sent, where:
P
λ = ∑ λi
i =1
z
Packet loss:
β packetloss = TotalDataT osend − DataBeingS ent
24
2
Exponential Process Time z
M/M/1 queue is chosen to reflect the exponential distribution of
the packet size
z
We use the Bluetooth default MTU plus the Bluetooth header
as our testing packet for all types of data.In reality the Bluetooth
packet size is not fixed, but it is variable, and therefore it can be
exponentially distributed.
z
Number of customers in the queue:
N =
P
∑ λW
i =1
25
M/M/1 System
i
i
Results
26
QoS-Aware Scheduling [3]
27
z
Round Robin policy, a number of time slots may be wasted due
to the guard time for piconet switching and the exchange of
POLL-NULL packets
z
devices are often required to operate under limited battery
capacity
z
We propose a mechanism to support the power-efficient
operation of a Bluetooth scatternet while guaranteeing various
QoS requirements of Bluetooth devices
A solution criticism
28
z
the scatter mode with credit scheme is promising and provides
all of the links of a PMP node with fair service opportunities.
z
However the uniform distribution of service opportunities is not
an efficient policy
z
In addition, Bluetooth devices are often required to operate
under limited battery capacity.
z
Accordingly, we must minimize the number of unnecessary
piconet switching events for the low-power operation of
Bluetooth scatternets.
SCATTER MODE FOR BLUETOOTH SCATTERNET
SCHEDULING
29
z
Participant in Multiple Piconets (PMP)
z
A Presence Point (PP) is a rendezvous point at which the
master of a piconet and a PMP node meet, and it is composed
of two consecutive slots
z
During a Communication Event (CE), both devices stay in the
same piconet and may communicate with each other
SCATTER MODE FOR BLUETOOTH SCATTERNET
SCHEDULING (cont)
30
z
scatter mode employs the credit scheme as its inter-piconet
scheduling algorithm. In order to assign a priority to each link
associated with each piconet in a PMP node of a scatternet, a
counter is maintained for each of these links, whose value is
debited or credited depending on the link’s utilization
z
In addition, a temporary account is maintained for a PMP node.
If the counter of another link at the upcoming PP has a higher
credit, the ongoing CE is aborted.
z
Once a slot of a link is used for communication, the credit
account of the link is automatically decreased by one.
SCATTER MODE FOR BLUETOOTH SCATTERNET
SCHEDULING (cont)
31
z
In order to keep the sum of all the credits among all the links
constant, one credit per slot should be increased in the
temporary account for the PMP node while one credit of the
polled link is decreased in the corresponding account.
z
As soon as the temporary account reaches M credits, where M
is the number of links of the PMP device, they are distributed
equally amongst all of the credit accounts of the M links
z
The unused credits of a broken CE caused by POLL-NULL
sequences are equally redistributed to the other links.
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED N Swith _ th
QoS-aware MAC scheduling framework
32
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED NSwith_ th (cont)
33
z
In scatter mode, it is recommended that NSwith_ th should be
set to T pp , an interval between two consecutive PPs in slots,
which is fixed at 16.
z
Thus, the scatter mode with basic credit scheme only
focuses on the fairness among the connected links of a PMP
node.
z
In order to improve the power-efficiency and to satisfy the
QoS requirements of a Bluetooth scatternet, we propose to
change the N Swith _ th adaptively according to the polling
interval of the scatternet, Tscatter_ poll , which is the QoS
parameter in the MAC layer of a Bluetooth scatternet.
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED NSwith_ th (cont)
34
Variation of credits at each piconet link in a scatternet to
compute N Switch _ th ,i and to support QoS requirements
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED N Swith _ th (cont)
z
For link i to be serviced at the nth PP after the piconet switching
event from link k to link j, we have:
z
where M is the number of links of the PMP node, ci and cj are
the credit values of link i and j, respectively, when the piconet
switching event from link k to link j has occurred, ,is the time
interval between two successive PPs,
and
x.
35
denotes the largest integer which is less than or equal to
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED N Swith _ th (cont)
36
z
In order to guarantee the QoS requirement of link i, the
parameter, Tscatter _ poll ,i , has to be taken into consideration as
follows.
z
where ti is the elapsed time since the most recent CE of link i.
Since N Switch _ th ,i is an integer value, the following relation can
be derived:
THE PROPOSED SCHEDULING POLICY USING THE
OPTIMIZED N Swith _ th (cont)
Summary of proposed algorithm
37
Simulation results
38
average packet arrival rate is one packet per slot
Simulation results (cont)
Throughput variations of link 1
39
Throughput variations of link 2
Simulation results (cont)
Throughput variations of link 3
40
Throughput variations of flow 1
Simulation results (cont)
41
Number of piconet switching events
Development of Wireless Peer-to-Peer
Games in J2ME [4]
42
z
It is expected that by 2006, wireless gaming will generate $17.5
billion in annual revenue worldwide
z
The development of games for wireless devices brings new
challenges to the developer, such as minimizing game data,
make games for small screens, adjust the control of games to
fit the keypad on wireless devices etc
z
Most mobile phones have support for J2ME. In an ideal world,
this would solve all portability issues of creating games for
various devices
z
However, there are also benefits: J2ME applications are
packed in a standardized way. It is even possible to use active
network support
Classification Framework for Mobile
Peer to peer Games
z
The motivation for creating the classification framework was
twofold:
- we wanted to identify the various types of peer-to-peer
games to examine their characteristics
- Second, we wanted to investigate how the various
categories of mobile peer-to-peer games could be
implemented using J2ME and the Java Bluetooth API
z
43
The usual way of classifying games is to divide games into
genres that reflect the game experience. Such classifications
are used by magazines, shops and web sites to make it easier
for the reader to focus on his preferred type of games
Classification Framework for Mobile
Peer to peer Games (cont)
44
z
device can be used to identify the user
z
device can function according to the user preferences when
interacting with other users
z
device has a high availability rate of the users
z
Proximity-based ad hoc interaction, enabled by mobile phones
and personal area networks, is referred to as impromptu
collaboration
Classification Framework for Mobile
Peer to peer Games (cont)
Impromptu collaboration is recognizable as being
z opportunistic, the technology enables people to take advantage
of opportunities that present themselves
45
z
spontaneous, the collaboration effort is not planned in any way
in advance
z
proximity based, the peers have to be physically collocated
z
transient, the interaction between peers can be very short
Classification Framework for Mobile
Peer to peer Games (cont)
46
z
We discuss to dimensions, the first describes how the users
interact and to what degree the devices interact on behalf of the
user. User interaction of peer-to-peer games can be divided
into the following categories:
z
I1 Controlled: The user interactions of the gamers are
controlled through a well-defined protocol, where one of the
peers in the network must be a master controlling the user
interaction
Classification Framework for Mobile
Peer to peer Games (cont)
47
z
I2 User interaction: The users have explicitly to trigger actions
that will cause interaction (exchange of data) with other gamers
z
I3 Automatic triggered: The mobile device of a gamer
searches for other gamers nearby, and if one is found it can
trigger an action to get the gamers attention (sound or vibration)
z
I4 Automatic: In this category, the devices of the gamers
interact without the user interacting with the game itself
Classification Framework for Mobile
Peer to peer Games (cont)
48
z
The second dimension of the classification framework focuses
on synchronization and update of data between the peers. This
dimension is divided into three categories:
z
U1 Asynchronous: Asynchronous update is for network
games where update between the peers is not time critical, but
can be updated whenever possible
z
U2 Synchronous: The peers participating are depending on
frequent update of data to be able to play the game
z
U3 Real-time: The games rely on heavy data exchange
between peers in order to give users a game experience
Classification Framework for Mobile
Peer to peer Games (cont)
The P2P Game Classification Matrix
49
Slow Device Discovery
50
z
The goal of the is to find all surrounding Bluetooth devices
within the network range. After that, the devices start to
handshake and connect
z
The time variation has a major impact on the usability of peerto-peer games in J2ME. When gamers want to join a game, all
gamers must wait until a complete discovery process has
completed (from 18 to 25 seconds).
Bluetooth Transfer Speed
51
z
The theoretical bandwidth for Bluetooth 1.0 is 1.1 Mbits/sec, but
this bandwidth is not often reachable in practical use.
z
For 1 meter, the average transfer rate was 21 KBps. The
variation in transfer rates of the 30 runs of the distance of 1
meter was very small
z
For 6 meters, the rate ranged from 19 up to 26 KBps and the
average rate was also here 21KBps
z
For the 10 meters test, the variation of transfer rates was
significant. The data rate ranged from 4 to 38 KBps while the
average was as low as 12.3 KBps
Topology of Bluetooth Devices
52
z
only one group of gamers can be simultaneously connected,
and one gamer can only be connected to one group at a time
z
In theory, a Bluetooth master can connect to seven Bluetooth
slaves at the same time
z
Ericsson P900, one other device, Siemens S65 three other
devices, while the Nokia 6600 seven other devices
z
Thins makes it hard for the game developers to provide support
for their network games
Extra Resource Consumption and
Other issues
53
z
The program should not consume too much memory and CPU
z
support for multitasking in the operating system
z
a J2ME application does not give the same user experience
when run on different mobile phones
Support for Framework Categories in
the Bluetooth API
z
I1 Controlled, is fully supported in the Bluetooth API in J2ME
z
I2 User interaction, can also be implemented in the Bluetooth
API in J2ME even through it is not directly supported through
the master-slave paradigm
z
I3 Automatic triggered, can be implemented using the
Bluetooth API but will not work optimally for the user
- the long discovery time
- run the game in foreground
z
54
I4 Automatic, suffers from the same problems as I3
Support for Framework Categories in
the Bluetooth API (cont)
55
z
The two first groups, U1 Asynchronous and Synchronous,
will not be difficult to support in the Bluetooth API in J2ME as
small amount of data is exchanged between the devices
z
support for U3 Real-time applications is limited due to the
maximum practical data transfer in Bluetooth for mobile phones
is about 10KBps
z
To summarize, we can see that the categories I1, I2 and U1
and U2 is well supported in J2ME Bluetooth API
implementations in existing mobile phones
References
56
z
[1] IEEE POTENTIALS, McDermott-Wells
z
[2] Queueing Model for Bluetooth Multipoint Communicntions
Sami, Kibria, Alice S. Rueda, Jose A. Rueda
z
[3] Power-Efficient and QoS-Aware Scheduling in Bluetooth
Scatternet for Wireless PANs, Yang-Ick Joo, Tae-Jin Lee, Doo
Seop Eom, Yeonwoo Lee, and Kyun Hyon Tchah
z
[4] Issues related to Development of Wireless Peer-to-Peer
Games in J2ME, Alf Inge Wang, Michael Sars Norum