Providing Delay Guarantees in Bluetooth Rachid Ait Yaiz and Geert Heijenk International Conference...
-
Upload
abner-mosley -
Category
Documents
-
view
214 -
download
1
Transcript of Providing Delay Guarantees in Bluetooth Rachid Ait Yaiz and Geert Heijenk International Conference...
Providing Delay Guarantees in Bluetooth
Rachid Ait Yaiz and Geert HeijenkInternational Conference on Distributed Computing Systems Workshops (ICDCSW’03)
Outline
Introduction The Guaranteed Service approach
Implementation of the Guaranteed Service approach in Bluetooth
Evaluation Conclusions
Introduction
Bluetooth uses a polling mechanism to divide bandwidth among the participants
Many polling mechanisms are proposed None of the studied pollers is able to guarant
ee packet delay bounds in its current state This paper presents a polling mechanism
that is able to guarantee delay bounds in an efficient manner
The Guaranteed Service Approach
Guaranteed service guarantees datagrams will arrive within the guaranteed delivery time and will not be discarded due to queue overflows
RFC 2212, IETF
WFQ
token rate, r
bucket size, b
per-flowrate, R
D = b/Rmax
arrivingtraffic
The Guaranteed Service Approach
Provides a requested fluid model bandwidth R, then a delay bound dmax dmax can be computed given a requested fluid model bandwidth R by
RprD
R
CM
pRrDR
CM
rp
Rp
R
Mb
d
tottot
tottot
,
,
max
•D: rate-dependent deviation•C:rate-independent deviation
–Ctot and Dtot are the sum of the deviations taken over all network elements in the GS path.
•p:peak rate•r:token rate •b:bucket size •m:minimum policed unit •M:maximum transfer unit
The Guaranteed Service Approach
If an application specifies its traffic using a token bucket traffic specification
If the network elements in the GS path export their deviation from the fluid model Provided that Dtot<dmax ,a fluid model service rat
e R can be requested such that a desired delay bound dmax is achieved
Guaranteed service does not control the minimal or average delay of datagrams, merely the maximal queueing delay
Implementation of the Guaranteed Service Approach in Bluetooth
The provisioning of Guaranteed Service in a network requires The source to provide a traffic
specification A desired delay bound Requires the receiver to calculate the
proper bandwidth request
Implementation of the Guaranteed Service Approach in Bluetooth
Furthermore Requires the network elements to
compute and export their deviation from the fluid model
Requires a mechanism that transports all specifications and requests between the source,the destination, and the intermediate network elements
Requires the network elements to perform admission control, and to schedule the guaranteed service traffic as promised
Implementation of the Guaranteed Service Approach in Bluetooth
In this paper, we focus on the determination of the C and D error terms As the C and D error terms and the
admission control are directly related to the polling mechanism
We restrict ourselves to an ideal radio environment where no transmission errors occur and where retransmissions are not needed
Planning Polls With a Fixed Time Interval
Xi:inter-poll timeSi,j,k(li,j) : Transmission time
Planning Polls With a Fixed Time Interval
A planned poll can be delayed by a period of at most yi
The Guaranteed Service provides the means to communicate this deviation to the requester . we accept this initial delay and propagate it
to the exported error terms
Determining the value of Xi
The transmission of a packet j of flow i will be completed at most a time period xi+yi+lij*xi Initial delay of xi+yi A packet j of flow i will be served within a ti
me period lij*xi
Determining the value of Xi
After an initial delay of xi+yi ,all segments of a packet j of flow i are served within a time period Lij/Ri, following must hold
ijiii
ji
ji
i
ijiii
jiiji
MLmR
l
L
x
thusand
MLmR
Lxl
,,
,
,,
,
Determining the value of Xi
Poll efficiency єpi,j the average number of bytes per poll
Associated with packet j of flow i also a result of the segmentation policy that is
followed as well as the set of baseband packet types that is allowed to be used.
Minimum poll efficiency of a flow i
)6(minmin
,
,min
, Rix
l
Li
ijiii
pi
ji
ji
MLmp
Determining the value of Yi
If at random one of the planned polls is chosen and executed, all the flows may have to wait for all the other flows Each flow will experience the same large value of yi
maximum time have to wait for is minimized. if Each flow is assigned a priority polls for a particular flow only have to wait for pol
ls for flows that are assigned a higher priority
Exporting C and D Terms
The deviation δFi of the polling mechanism from the fluid model with respect to serving flow i obeys
Then form (6)
Thus Ci= Di=
maxiii sxF
maxmin
ii
pi s
RF i
min
ip max
is
Admission Control
A planned poll should never be delayed by waiting polls for the same flow. Achieved by ensuring that yi<xi
The allowed fluid model bandwidth Ri is inversely proportional to yi
The admission control should reassign the priorities such that all the GS flows, including the new one, comply with (9)
)9(min
i
pi Ry i
Evaluation
Evaluation
For the GS flows,the packet sizes are uniformly distributed Minimum size of 144 bytes, mi=144 byte Maximum size of 176 bytes, Mi=176 byte
For the BE flows the packet sizes are of a fixed size of 176 bytes The sources of flows 5/6, 7/8, 9/10 and 11/12
generate BE traffic at a data rate of 41.6 kbps, 47.2 kbps, 52.8 kbps and 58.4 kbps respectively.
Evaluation
The allowed baseband packet types are DH1 and DH3.
Because of the fixed intervals between packet generations, and because of the packet size distribution The remaining parameters of the token bu
cket specification are
Evaluation
The algorithm used to determine yi gives y1=3.75ms, y2=7.5ms, y3=y4=11.25ms
Thus, get R
bytesCiip
144min msDi 75.3
1600
32
skbytesms
bytes
yR
i
pi
i /8.1225.11
144min
Evaluation
Requested delay bound dmax
msmsskbyte
bytesbytesD
R
CMd tot
tot 75.2875.3/8.12
144176max
Simulation results
Conclusions
This polling mechanism is highly determining with respect to the delay that packets experience in a piconet.
Further Works
The evaluation of the proposed polling mechanisms in a non-ideal radio environment Transmission errors may occur where retra
nsmissions are needed