1
Token Bucket Based CAC and Packet Scheduling for IEEE 802.16
Broadband Wireless Access Networks
Chi-Hung Chiang ([email protected])
Tzu-Chieh Tsai ([email protected])
CCNC 2006
01/09/06
2
Outline
• Introduction– Problem– IEEE 802.16 Standard– Related Work– Motivation
• 802.16 CAC and Uplink Packet Scheduling• Token Rate Estimation Model• Simulation Results• Conclusions & Future Work
3
What is IEEE 802.16
4
Problem
• The IEEE 802.16 standard defines QoS classes, but it does not completely define how to achieve the QoS support– Packets scheduling is the key part,
which is not defined in the 802.16 standard
5
IEEE 802.16 Standard
• Four QoS classes– Unsolicited Grant Service (UGS)– Real-time Polling Service (rtPS)– Non-real-time Polling Service (nrtPS)– Best Effort (BE)
Class name Traffic type Application
UGS Real-time Constant Bit Rate (CBR) Voice over IP (VoIP)
rtPS Real-time Various Bit Rate (VBR) Real-time video
nrtPS Non-real-time Bandwidth-sensitive FTP
BE Non-real-time HTTP, Telnet
6
Point-to-MultiPoint mode
SS
7
• Operation process of 802.16
• 802.16 standard only defined the scheduling of UGS class– Allocate fixed bandwidth during fixed time
IEEE 802.16 Standard
8
• Frame Structure of 802.16
• The downlink scheduling is simpler than uplink, hence we focus on uplink scheduling
IEEE 802.16 Standard
9
Token Bucket
• Mean rate: token rate r• Burst size: bucket size b• Maximum size generated during time
t: rt+b
10
Related Work
• More complete 802.16 QoS architecture: [4]– Our main reference– Call admission control (CAC) and uplink packet
scheduling were both proposed in this paper– [4] Kitti Wongthavarawat, and Aura Ganz,
“Packet scheduling for QoS support in IEEE 802.16 broadband wireless access systems”, International Journal of Communication Systems, vol. 16, issue 1, February 2003, pp. 81-96
11
Scheduling Architecture
proposed by [4]• Each connection i is controlled by a
pair of parameters– Token rate ri and bucket size bi
• Main scheduling architecture in [4]
12
Earliest Deadline First (EDF)
• Calculate the number of arriving packets during last frame
• Calculate the deadline of these packets and record them into a database
• Grant bandwidth according to the database
13
Earliest Deadline First (EDF)
• Calculate the deadline– di: maximum delay requirement of the
connection i
14
Earliest Deadline First (EDF)
• Calculate the deadline– di must satisfy: di/f=mi, where
• mi≧2
• mi is an integer – t-f+di-f and t-f+di are integral multiples of f
15
rtPS CAC proposed by [4]
• This is not the sufficient condition for guaranteeing the di of the rtPS connection
16
Motivation
• The QoS architecture in [4] has some shortcomings– The CAC is not precise enough– The scheduling may cause starvation
• Not all traffic flows originally have token bucket parameters– A model is needed to calculate the
appropriate token bucket parameters of a traffic flow
17
• Introduction• Our 802.16 CAC and Uplink Packet
Scheduling– CAC– Uplink packet scheduling
• Token Rate Estimation Model• Simulation Results• Conclusions & Future Work
18
CAC
• Assume an rtPS connection i has a burst from t to t+6f– The maximum generating size: 6rif+bi
– bi may be consumed in a single frame when the traffic is very high
19
CAC
• If is 3, two frames can share the bi
– In this situation, the maximum bandwidth requirement in a frame is rif+
bi
2
1
/fdi
20
CAC
• For guaranteeing the di of an rtPS connection i, BS should at least grant bandwidth
• The total bandwidth requirement of rtPS connections CrtPS is
2fd and f
dm where,
1-m
bfr i
ii
i
ii
......(1)....................1-m
bfrC
rtPSN
i i
iirtPS
21
CAC
• For preventing starvation, we set up a “threshold” parameter for each class– “threshold” here means minimum
guaranteed bandwidth for each class– If the bandwidth usage of some class
exceed its threshold, its priority over accessing resource will be downgraded
22
CAC
• Notations– Cuplink: The total capacity of the uplink sub-frame– CUGS: The capacity used by UGS connections– CrtPS: The total bandwidth requirements of rtPS
connections– CnrtPS: The capacity used by nrtPS connections– CBE: The capacity used by BE connections– TUGS: The bound parameter of UGS class– TrtPS: The bound parameter of rtPS class– TnrtPS: The bound parameter of nrtPS class– TBE: The bound parameter of BE class– ri: The token rate of the new connection i
23
CAC
• CAC algorithm for UGSCremain=Cuplink-CUGS-CrtPS-CnrtPS-CBE
If Cremain≧ri, we accept it
Else
If CBE > TBE, we decrease CBE to get more bandwidth until Cremain==ri or CBE==TBE
If Cremain < ri and CnrtPS > TnrtPS, we decrease CnrtPS to get more bandwidth until Cremain==ri or CnrtPS==TnrtPS
If Cremain < ri and CrtPS > TrtPS, we decrease CrtPS to get more bandwidth until Cremain≧ri or CrtPS≦TrtPS (degrade the ri of some rtPS connections and update CrtPS)
If Cremain≦ri, we accept it. Else we deny it.
24
CAC
• CAC algorithm for rtPSCremain=Cuplink-CUGS-CnrtPS-CBE
Calculate new CrtPS by using (1)
If Cremain≧CrtPS, we accept it
Else
If CBE > TBE, we decrease CBE to get more bandwidth until Cremain== CrtPS or CBE==TBE
If Cremain < CrtPS and CnrtPS > TnrtPS, we decrease CnrtPS to get more bandwidth until Cremain== CrtPS or CnrtPS==TnrtPS
If Cremain < CrtPS, CrtPS < TrtPS, and CUGS > TUGS, we decrease CUGS to get more bandwidth until Cremain≧CrtPS or CUGS≦TUGS (degrade the ri of some UGS connections and update CUGS)
If Cremain≦CrtPS, we accept it. Else we deny it.
25
CAC
• CAC algorithm for nrtPSCremain=Cuplink-CUGS-CrtPS-CnrtPS-CBE
If Cremain≧ri, we accept it
Else
If CBE > TBE, we decrease CBE to get more bandwidth until Cremain==ri or CBE==TBE
If Cremain < ri, CnrtPS < TnrtPS, and CrtPS > TrtPS, we decrease CrtPS to get more bandwidth until Cremain≧ri or CrtPS≦TrtPS (degrade the ri of some rtPS connections and update CrtPS)
If Cremain < CrtPS, CnrtPS < TnrtPS, and CUGS > TUGS, we decrease CUGS to get more bandwidth until Cremain≧CrtPS or CUGS≦TUGS (degrade the ri of some UGS connections and update CUGS)
If Cremain≦CrtPS, we accept it. Else we deny it.
26
CAC
• CAC algorithm for BEAccept it
Cremain=Cuplink-CUGS-CrtPS-CnrtPS-CBE
If Cremain < ri
If CBE > TBE and CnrtPS > TnrtPS, we decrease CnrtPS to get more bandwidth until Cremain== ri or CnrtPS==TnrtPS
If Cremain < ri, CBE < TBE, and CrtPS > TrtPS, we decrease CrtPS to get more bandwidth until Cremain≧ri or CrtPS≦TrtPS
(degrade the ri of some rtPS connections and update CrtPS)
If Cremain < ri, CBE < TBE, and CUGS > TUGS, we decrease CUGS to get more bandwidth until Cremain≧CrtPS or CUGS≦TUGS (degrade the ri of some UGS connections and update CUGS)
27
Uplink Packet Scheduling
• Step 1.– Calculate the arriving packets of each
rtPS connection during the last frame– Calculate the deadlines of these packets
by applying (1) and record them in the database
• Step 2.– Allocate bandwidth to UGS connections
according to their token rates
28
Uplink Packet Scheduling
• Step 3.– Allocate bandwidth to rtPS connections
according to the database. We limit that the maximum allocated size of each rtPS connection is packets due to degradation
1-m
bfr
i
ii
29
Uplink Packet Scheduling
• Step 4.– Assume the total bandwidth
requirements of nrtPS connections and BE connections are RnrtPS and RBE. We allocate Min(RnrtPS, TnrtPS) bandwidth to nrtPS connections first. Then we allocate Min(RBE, TBE) bandwidth to BE connections
30
Uplink Packet Scheduling
• Step 5.– If there is remainder bandwidth, we look
if RnrtPS > TnrtPS. If RnrtPS > TnrtPS, we grant Min(remainder bandwidth, RnrtPS-TnrtPS) to nrtPS connections
• Step 6.– If there is remainder bandwidth, we look
if RBE > TBE. If RBE > TBE, we grant Min(remainder bandwidth, RBE-TBE) to BE connections
31
Uplink Packet Scheduling
• Step 7.– If there is remainder bandwidth and
there are nrtPS or BE connections that need BW-request contention opportunities, we allocate the remainder bandwidth to nrtPS connections and BE connections in order for BW-request contention periods
32
• Introduction• 802.16 CAC and Uplink Packet
Scheduling• Token Rate Estimation Model
– Case of infinite queue– Case of finite queue
• Simulation Results• Conclusions & Future Work
33
Token Rate Estimation Model
• Use a simple search algorithm to find appropriate token rate of a Poisson traffic flow given a reasonable bucket size
34
Case of Infinite Queue
• Predict the queuing delay of a Poisson traffic flow in the token bucket queue– Assume a Poisson traffic flow with
• Infinite queue
• Mean arrival rate λi
• Token rate ri
• Bucket size bi
– We analyze the problem by applying Markov Chain
35
Case of Infinite Queue
• Markov Chain– State(t, p): t is the amount of tokens in the
bucket and p is the amount of packets in the queue
– We use discrete Markov Chain• The time interval is 1/ri
• The probability that n packets arrives during time interval 1/ri is
– From State(bi, 0) to State(0, )
i
i-n
r where,
n!
eP(n)
36
Case of Infinite Queue
• States
37
Case of Infinite Queue
• We denote State(t, p) by π(bi-t+p) and assume
• We can list the equations
2k
P(k)M
.....(3)1nfor P(0)1)(nk)-1P(n(k)MP(0)(n)
2)(1)......(P(0)M(0)1-n
0k
38
Case of Infinite Queue
• We can derive
– given ri > λi
)-(r2r
-2r(k)-1d
iii
ii1-b
0k
avg
i
39
Case of Finite Queue
• Predict the queuing delay and loss rate of a Poisson traffic flow in the token bucket queue– Assume a Poisson traffic flow with
• Finite queue whose size is q• Mean arrival rate λi • Token rate ri
• Bucket size bi
– We also analyze the problem by applying Markov Chain
40
Case of Finite Queue
• Markov Chain– From State(bi, 0) to State(0, q-1)
• States
41
Case of Finite Queue
• We denote State(t, p) by π(bi-t+p) and assume
• We can list the equations
2k
P(k)M
....(10)
k)-qP(b(k)P(0)1)-q(b
1n2-qbfor P(0)1)(nk)-1P(n(k)MP(0)(n)
)(1).....(9P(0)M(0)
2-qb
0k
ii
1-n
0k
i
i
42
Case of Finite Queue
• We can derive
– Where
i
1-qb
0k 1,0)k-Max(bjavg
r
NP(j)(k)
d
i
i
otherwise 0.5-q),b-kMin(j
1q),b-kMin(jfor q),b-kMin(jN
i
ii
43
Case of Finite Queue
• The average loss rate Lavg can be expressed as– [State(bi, 0)•(1•P(bi+q+1)+2•P(bi+q+2)+ 3•P(bi+q+3)+
…)+State(bi-1, 0)•(1•P(bi+q)+2•P(bi+q+1)+ 3•P(bi+q+2)+…)+State(bi-2, 0)•(1•P(bi+q-1)+2•P(bi+q)+ 3•P(bi+q+1)+…)+..State(0, 1)•(1•P(q)+2•P(q+1)+ 3•P(q+2)+…)+State(0, 2)•(1•P(q-1)+2•P(q)+ 3•P(q+1)+…)+..State(0, q-1)•(1•P(2)+2•P(3)+ 3•P(4)+…)]/(λi/ri)
44
Case of Finite Queue
• We can derive
i
i
1-qb
0k k-1qbj
i
avg
r
)b-q-k(jP(j)(k)
L
i
i
45
• Introduction• 802.16 CAC and Uplink Packet Scheduling• Token Rate Estimation Model• Simulation Results
– CAC and uplink packet scheduling– Token rate estimation model
• Case of infinite queue• Case of finite queue
• Conclusions & Future Work
46
CAC and Uplink Packet Scheduling
• Uplink capacity: 37500000 bps• Frame duration: 1 ms• Simulation time: 150 ms• Size of BW-request: 48 bits• There are 100 UGS, nrtPS, and BE
connections• All connections send data in full
speed and didn’t terminate
47
CAC and Uplink Packet Scheduling
• Parameters of each class
Class Token rate
(bps)
Bucket size
(bits)
Delay
req.(ms)
Packet size
(bits)
Threshold
(bps)
UGS 192000 64 - 64 4000000
rtPS 640000 15000 20 256 4000000
nrtPS 2000000 15000 - 256 6000000
BE 512000 8000 - 128 8000000
48
CAC and Uplink Packet Scheduling
• Avg. rtPS delay and acceptance of rtPS calls v.s. number of rtPS calls
02468
1012141618
100 200 400 800 1600
number of rtPS calls
acce
ptan
ce ra
tio o
f rtP
S ca
lls (%
)
modified
original
0
10
20
30
40
50
100 200 400 800 1600
number of rtPS calls
avg
rtPS
dela
y (m
s)
modified
original
49
CAC and Uplink Packet Scheduling
• Avg. delay and throughput v.s. number of rtPS calls
0
2
4
6
8
10
12
14
16
18
100 200 400 800 1600
number of rtPS calls
avg
thro
ughp
ut (1
06 bps
)
UGS
rtPS
nrtPS
BE
0
5
10
15
20
25
30
100 200 400 800 1600
number of rtPS calls
avg
thro
ughp
ut (1
06 bps
)
UGS
rtPS
nrtPS
BE
modified
original
50
Case of Infinite Queue
• Simulation time ms• Parameters
Parameter Value
mean arrival rate (bps) 640000
bucket size (bits) 5120
packet size (bits) 512
710rate arrivalmean
1
51
Case of Infinite Queue
• Avg. delay v.s. token rate
0
50
100
150
200
250
token rate (bps)
avg
queu
ing
dela
y (m
s)
Simulation
Math
52
Case of Finite Queue
• All parameters are the same as the last case but an extra parameter– Queue size: 5120 bits
53
Case of Finite Queue
• Avg. delay and loss rate v.s. token rate
0
5
10
15
20
25
30
token rate (bps)
avg
queu
ing
dela
y (m
s)
SimulationMath
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
token rate (bps)
avg
queu
ing
loss
rat
e (r
atio
)
SimulationMath
54
• Introduction• 802.16 CAC and Uplink Packet
Scheduling• Token Rate Estimation Model• Simulation Results• Conclusions & Future Work
55
Conclusions & Future Work
• We present– CAC and uplink packet scheduling
• the delay requirements of real-time traffic were guaranteed
• Starvation was prohibited
– A model that can determine the appropriate token rate of a Poisson traffic flow given the queuing delay and loss rate requirements• We can precisely predict the queuing delay
and loss rate of a traffic flow given some necessary parameters
56
Conclusions & Future Work
• Future work– We may extend the token estimation
model to the traffic flows that are not Poisson arrival in the future
– An integration scenario is also one of the main objectives in the future.
Top Related