56
1 Queuing and QoS models in Bluetooth Presented by: Mohammad Hosein Yarmand ECE 731 course October 2006
1
Queuing and QoSmodels in
Bluetooth
Presented by:Mohammad Hosein Yarmand
ECE 731 courseOctober 2006
2
What is Bluetooth? [1]
Bluetooth is a standard for short range, low power, low cost wireless communication that uses radio technology
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
The resulting Bluetooth specification is open and freely available at the official Bluetooth website www.bluetooth.org
3
Usages
intelligent devices (PDAs, cell phones, PCs)
data peripherals (mice, keyboards, joysticks, cameras, digitalpens, printers, LAN access points)
audio peripherals (headsets, speakers, stereo receivers)
embedded applications (automobile power locks, grocerystore updates, industrial systems, MIDI musical instruments)
4
Network configuration
Network configuration of Bluetooth (a) piconet and (b) scatternet
5
Network configuration
Piconets: a cluster of up to eight Bluetooth devices
scatternet: Two piconets can be connected through a common Bluetooth device (a gateway or bridge) to form a scatternet
These enable devices which are not directly communicating with each other, or which are out of range of another device, toexchange data through several hops in the scatternet.
6
Protocol stack
7
Protocol stack (cont)
The Transport group protocols allow Bluetooth devices to locate each other, and to manage physical and logical linkswith higher layer protocols and applications
These protocols support both asynchronous and synchronoustransmission
The Application group consists of actual applications that use Bluetooth links. They can include legacy applications as well asBluetooth-aware applications
8
Protocol stack (cont)
The Middleware Protocol group includes industry-standard protocols and Bluetooth protocols.Industry standard : PPP, IP, TCP, WAP, and object exchange (OBEX) protocols.
Bluetooth :– 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.
9
Communication
- 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
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.
10
Communication
Bluetooth uses polling-based packet transmission. All communication between devices takes place between a master and a slave, using TDD.
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 immediatelyfollowing the one in which it was polled.
The master transmits only in even numbered time slots, while the slaves transmit only in odd-numbered time slots.
11
Piconet
One device holds the role of master, while the rest of the devices are slaves
maximum of seven slaves can be active in a piconet at any given point in time
the rest of the slaves must be “parked.” The maximum number of “parked” slaves is 255 per piconet
12
Piconet (cont)
Any Bluetooth device can function within a piconet as a master, a slave or a bridge.
These roles are temporary and exist only as long as the piconet itself exists.
The master device selects the frequency, the frequency-hopping sequence, the timing (when the hops will actually occur) and the polling order of the slaves.
The master is also responsible for instructing the slave devicesto switch to different device states for periods of inactivity.
13
Piconet (cont)
A master and slave must exchange address and clock information in order for the slave to join the master’s piconet.
Bluetooth devices each have a unique Global ID used to create a hopping pattern.
The master radio shares its Global ID and clock offset with each slave in its piconet, providing the offset into the hopping pattern.
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.
14
Piconet (cont)
A Bluetooth bridge device (or gateway) interconnects two or more piconets for multi-hop communication.
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.
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.
15
Device states
16
A queuing model [2]
We present a queuing model for Bluetooth multipoint connection systems
Assumptions: one piconet or scattemet as the main interest, all nodes have infinite buffer size, connection setup is assumed to be established
A two-level priority queuing system can maintain QoS services
The model is based on a non-preemption priority queue
17
QoS variables
Bandwidth: In order to allow applications to run sufficiently and smoothly over a Bluetooth wireless link, there must exist a certain amount of bandwidth
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.
The propagation delay is insignificant, and main delay factor is the queuing delay at the master node
18
QoS variables
Delay Variation: The difference between the minimum and the maximum delay within the system (jitter)
Throughput: The maximum amount of data received at some instant in time for a given traffic load
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
19
Bluetooth behavior mapped to QoS
One interest is to find out how Bluetooth QoS can support the four kinds of services
These services are described as traffic types:- continuous stream of data - VBR data - data in bursts - control system data.
Another interest is to see how the priority queue model affects the capacity of the Bluetooth system
20
Proposed priority queue model
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
The queue type that will be discussed here is the Head-of-the-line (HOL) priorities
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
21
Proposed priority queue model (cont)
22
Proposed priority queue model (cont)
The utilization factor:
the mean service time
The average delay, or waiting time (denoted by ), within the system:
PPP
_χλρ =_
χ
∑=
=P
pp
p
1
__χ
λλ
χ
μχχχ 1_
2
_
1
_===
0W
23
Proposed priority queue model (cont)
the delay time or wait time for a specific priority p:
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
∑∑==
==P
i
iiP
ii
iiW
1
_2
1_
_2
0 22
χλ
χ
χρ
∑∑+==
++=P
piPii
P
piiiiP WWWW
1
__
0 λχλχ
24
Proposed priority queue model (cont)
Since we are using a priority queue with two priorities we are able to derive equations for the delay time of each priority
The throughput ( ) = * packet size that is to be sent, where:
Packet loss:
)1(2 2
_2
112 ρ
χλ−
=W)1)(1(2 221
_222
_211
1 ρρρχλχλ−−−
+=W
λ
∑=
=P
ii
1λλ
β
entDataBeingSosendTotalDataTpacketloss −=β
25
Exponential Process Time - M/M/1 System
M/M/1 queue is chosen to reflect the exponential distribution ofthe packet size
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.
Number of customers in the queue:
∑=
=P
iiiWN
1λ
26
Results
27
QoS-Aware Scheduling [3]
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
devices are often required to operate under limited battery capacity
We propose a mechanism to support the power-efficient operation of a Bluetooth scatternet while guaranteeing various QoS requirements of Bluetooth devices
28
A solution criticism
the scatter mode with credit scheme is promising and provides all of the links of a PMP node with fair service opportunities.
However the uniform distribution of service opportunities is notan efficient policy
In addition, Bluetooth devices are often required to operate under limited battery capacity.
Accordingly, we must minimize the number of unnecessary piconet switching events for the low-power operation of Bluetooth scatternets.
29
SCATTER MODE FOR BLUETOOTH SCATTERNET SCHEDULING
Participant in Multiple Piconets (PMP)
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
During a Communication Event (CE), both devices stay in the same piconet and may communicate with each other
30
SCATTER MODE FOR BLUETOOTH SCATTERNET SCHEDULING (cont)
scatter mode employs the credit scheme as its inter-piconet scheduling algorithm. In order to assign a priority to each linkassociated 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
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.
Once a slot of a link is used for communication, the credit account of the link is automatically decreased by one.
31
SCATTER MODE FOR BLUETOOTH SCATTERNET SCHEDULING (cont)
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.
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
The unused credits of a broken CE caused by POLL-NULL sequences are equally redistributed to the other links.
32
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED
QoS-aware MAC scheduling framework
thSwithN _
33
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED (cont)thSwithN _
In scatter mode, it is recommended that should be set to , an interval between two consecutive PPs in slots, which is fixed at 16.
Thus, the scatter mode with basic credit scheme only focuses on the fairness among the connected links of a PMP node.
In order to improve the power-efficiency and to satisfy the QoS requirements of a Bluetooth scatternet, we propose to change the adaptively according to the polling interval of the scatternet, , which is the QoSparameter in the MAC layer of a Bluetooth scatternet.
thSwithN _pollscatterT _
thSwithN _ppT
34
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED (cont)
Variation of credits at each piconet link in a scatternet to compute and to support QoS requirements
thSwithN _
ithSwitchN ,_
35
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED (cont)
For link i to be serviced at the nth PP after the piconet switching event from link k to link j, we have:
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 denotes the largest integer which is less than or equal to x .
thSwithN _
36
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED (cont)
In order to guarantee the QoS requirement of link i, the parameter, , has to be taken into consideration as follows.
where is the elapsed time since the most recent CE of link i. Since is an integer value, the following relation can be derived:
thSwithN _
ithSwitchN ,_
ipollscatterT ,_
it
37
THE PROPOSED SCHEDULING POLICY USING THEOPTIMIZED (cont)
Summary of proposed algorithm
thSwithN _
38
Simulation results
average packet arrival rate is one packet per slot
39
Simulation results (cont)
Throughput variations of link 1 Throughput variations of link 2
40
Simulation results (cont)
Throughput variations of link 3 Throughput variations of flow 1
41
Simulation results (cont)
Number of piconet switching events
42
Development of Wireless Peer-to-Peer Games in J2ME [4]
It is expected that by 2006, wireless gaming will generate $17.5billion in annual revenue worldwide
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
Most mobile phones have support for J2ME. In an ideal world, this would solve all portability issues of creating games for various devices
However, there are also benefits: J2ME applications are packed in a standardized way. It is even possible to use active network support
43
Classification Framework for Mobile Peer to peer Games
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
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
44
Classification Framework for Mobile Peer to peer Games (cont)
device can be used to identify the user
device can function according to the user preferences when interacting with other users
device has a high availability rate of the users
Proximity-based ad hoc interaction, enabled by mobile phones and personal area networks, is referred to as impromptu collaboration
45
Classification Framework for Mobile Peer to peer Games (cont)
Impromptu collaboration is recognizable as being opportunistic, the technology enables people to take advantage of opportunities that present themselves
spontaneous, the collaboration effort is not planned in any way in advance
proximity based, the peers have to be physically collocated
transient, the interaction between peers can be very short
46
Classification Framework for Mobile Peer to peer Games (cont)
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:
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
47
Classification Framework for Mobile Peer to peer Games (cont)
I2 User interaction: The users have explicitly to trigger actions that will cause interaction (exchange of data) with other gamers
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)
I4 Automatic: In this category, the devices of the gamers interact without the user interacting with the game itself
48
Classification Framework for Mobile Peer to peer Games (cont)
The second dimension of the classification framework focuses on synchronization and update of data between the peers. This dimension is divided into three categories:
U1 Asynchronous: Asynchronous update is for network games where update between the peers is not time critical, but can be updated whenever possible
U2 Synchronous: The peers participating are depending on frequent update of data to be able to play the game
U3 Real-time: The games rely on heavy data exchange between peers in order to give users a game experience
49
Classification Framework for Mobile Peer to peer Games (cont)
The P2P Game Classification Matrix
50
Slow Device Discovery
The goal of the is to find all surrounding Bluetooth devices within the network range. After that, the devices start to handshake and connect
The time variation has a major impact on the usability of peer-to-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).
51
Bluetooth Transfer Speed
The theoretical bandwidth for Bluetooth 1.0 is 1.1 Mbits/sec, but this bandwidth is not often reachable in practical use.
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
For 6 meters, the rate ranged from 19 up to 26 KBps and the average rate was also here 21KBps
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
52
Topology of Bluetooth Devices
only one group of gamers can be simultaneously connected, and one gamer can only be connected to one group at a time
In theory, a Bluetooth master can connect to seven Bluetooth slaves at the same time
Ericsson P900, one other device, Siemens S65 three other devices, while the Nokia 6600 seven other devices
Thins makes it hard for the game developers to provide support for their network games
53
Extra Resource Consumption and Other issues
The program should not consume too much memory and CPU
support for multitasking in the operating system
a J2ME application does not give the same user experience when run on different mobile phones
54
Support for Framework Categories in the Bluetooth API
I1 Controlled, is fully supported in the Bluetooth API in J2ME
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
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
I4 Automatic, suffers from the same problems as I3
55
Support for Framework Categories in the Bluetooth API (cont)
The two first groups, U1 Asynchronous and Synchronous, will not be difficult to support in the Bluetooth API in J2ME assmall amount of data is exchanged between the devices
support for U3 Real-time applications is limited due to the maximum practical data transfer in Bluetooth for mobile phones is about 10KBps
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
56
References
[1] IEEE POTENTIALS, McDermott-Wells
[2] Queueing Model for Bluetooth Multipoint CommunicntionsSami, Kibria, Alice S. Rueda, Jose A. Rueda
[3] Power-Efficient and QoS-Aware Scheduling in Bluetooth Scatternet for Wireless PANs, Yang-Ick Joo, Tae-Jin Lee, DooSeop Eom, Yeonwoo Lee, and Kyun Hyon Tchah
[4] Issues related to Development of Wireless Peer-to-Peer Games in J2ME, Alf Inge Wang, Michael Sars Norum
