1

Token Bucket Based CAC and Packet Scheduling for IEEE 802.16

Broadband Wireless Access Networks

Chi-Hung Chiang (g9203@cs.nccu.edu.tw)

Tzu-Chieh Tsai (ttsai@cs.nccu.edu.tw)

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.