1 / 56

Token Bucket Based CAC and Packet Scheduling for IEEE 802.16 Broadband Wireless Access Networks

CCNC 2006. 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). 01/09/06. Outline. Introduction Problem IEEE 802.16 Standard Related Work Motivation

gwyn
Download Presentation

Token Bucket Based CAC and Packet Scheduling for IEEE 802.16 Broadband Wireless Access Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CCNC 2006 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) 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)

  6. Point-to-MultiPoint mode SS

  7. IEEE 802.16 Standard • Operation process of 802.16 • 802.16 standard only defined the scheduling of UGS class • Allocate fixed bandwidth during fixed time

  8. IEEE 802.16 Standard • Frame Structure of 802.16 • The downlink scheduling is simpler than uplink, hence we focus on uplink scheduling

  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

  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

  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 UGS Cremain=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 rtPS Cremain=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 nrtPS Cremain=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 BE Accept 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

  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, )

  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

  38. Case of Infinite Queue • We can derive • given ri＞λ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

  42. Case of Finite Queue • We can derive • Where

  43. Case of Finite Queue • The average loss rateLavg 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

  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

  48. CAC and Uplink Packet Scheduling • Avg. rtPS delay and acceptance of rtPS calls v.s. number of rtPS calls

  49. CAC and Uplink Packet Scheduling • Avg. delay and throughput v.s. number of rtPS calls modified original

  50. Case of Infinite Queue • Simulation time ms • Parameters

More Related