1 / 49

Packet scheduling for QoS support in IEEE 802.16 broadband wireless access systems

Learn about packet scheduling and QoS support in IEEE 802.16 broadband wireless access systems, including proposed uplink scheduling and admission control mechanisms. Simulation results and conclusions are discussed.

beauchesne
Download Presentation

Packet scheduling for QoS support in IEEE 802.16 broadband wireless access systems

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. Packet scheduling for QoS support in IEEE 802.16 broadband wireless access systems Kitti Wongthavarawat and Aura Ganz Multimedia Networks Laboratory, Electrical and Computer Engineering Department, University of Massachusetts, Amherst, MA 01003, U.S.A 2003 John Wiley & Sons, Ltd. Presented by Jason L.Y. Lin OPLab, IM, NTU

  2. Outline • Introduction - IEEE 802.16 broadband wireless access system - QoS Architecture • Proposed uplink packet scheduling • Admission control • Simulation results • Conclusion OPLab, IM, NTU

  3. IEEE 802.16 broadband wireless access system • operates at 10-66 GHz (IEEE 802.16) with data rates of 32-130 Mbps • When the system uses TDM, the frame is subdivided into an uplink subframe and a downlink subframe. • uplink arbitration uses a TDMA MAC • The BS determines the number of time slots that each SS will be allowed to transmit in an uplink subframe. - UL-MAP, • The BS uplink scheduling module determines the IEs using BW-request OPLab, IM, NTU

  4. QoS Architecture OPLab, IM, NTU

  5. Admission control undefined by IEEE 802.16 Applications Connection classifier Uplink Packet Scheduling (UPS) Uplink scheduling for UGS service flow defined by IEEE 802.16 Uplink Scheduling for rtPS, nrtPS and BE service flow undefined By IEEE 802.16 Proposed signaling flow Signaling flow Data flow Proposed module IEEE 802.16 QoS architecture OPLab, IM, NTU

  6. QoS Architecture (cont’) • IEEE 802.16 defines： (1) the signaling mechanism for information exchange between BS and SS (2) the uplink scheduling for UGS service flow • IEEE 802.16 doesn’t define： (1) the uplink scheduling for rtPS, nrtPS, BE service flow (2) the admission control (3) Traffic Policing process OPLab, IM, NTU

  7. Roposed uplink packet scheduling OPLab, IM, NTU

  8. Roposed uplink packet scheduling (cont’) Signaling flow Proposed signaling flow Proposed module Data flow Proposed QoS architecture OPLab, IM, NTU

  9. Information module • The information module performs the following tasks: - retrieves the queue size information of each connection from the BW-Request messages - determines the number of packets (in bits) that arrived from rtPS connection in the previous time frame using the arrival-service curve concept - determines rtPS packets’ arrival time and deadline and updates this information in the scheduling databse module - queuing information from nrtPS and BE BW-Requests is passed directly to scheduling database module OPLab, IM, NTU

  10. Information module (cont’) OPLab, IM, NTU

  11. Information module (cont’) Assume current time is t, and the current frame is [t, t+f] OPLab, IM, NTU

  12. Scheduling database module OPLab, IM, NTU

  13. Scheduling database module (cont’) OPLab, IM, NTU

  14. Service assignment module • The service assignment module determines the UL-MAP 1. UGS packet scheduling (fixed bandwidth allocation) - after scheduling the packets, update 2. rtPS packet scheduling (EDF) - schedule the rtPS packets in the rtPS database until either there are no rtPS packets left or there is no more bandwidth left - after scheduling the packets, update [all bits allocated for rtPS] OPLab, IM, NTU

  15. Service assignment module (cont’) Two actions for the packets that missed their deadline in rtPS scheduling: (1) drop the packets (2) reduce the priority of the packets by moving them to the BE database 3. nrtPS packet scheduling (WFQ) - schedule the packets based on connections’ weights ( ) - after scheduling packets, update 4. BE packet scheduling (schedule packets equally) [all bits allocated for nrtPS] OPLab, IM, NTU

  16. Admission control • This mechanism will ensure that existing sessions’ QoS will not be degraded and the new session will be provided Qos support • A connection is admitted if : (1) there is enough bandwidth to accommodate the new connection (2) the newly admitted conection will receive QoS guarantees in terms of both bandwidth and delay (3) QoS of existing connections is maintained • The necessary condition that a rtPS connection i can be scheduled by our uplink packet scheduling with delay guarantees OPLab, IM, NTU

  17. Admission control (cont’) • Admission control for rtPS connections: Input: 1. a new rtPS connection requests with parameters , , 2. current network parameters: 3. Admission control procedure 1. If 2. If 3. check for delay violations of existing rtPS connections 4. update 5. pass token bucket parameters , to the traffic policing module OPLab, IM, NTU

  18. Admission control (cont’) • Admission control for UGS connections: Input: 1. a new UGS connection requests with parameters 2. current network parameters: 3. Admission control procedure 1. If 2. check for delay violations of existing rtPS connections 3. update 4. pass parameter to the traffic policing module OPLab, IM, NTU

  19. Admission control (cont’) • Admission control for nrtPS connections: Input: 1. a new nrtPS connection requests with parameters , 2. current network parameters: Admission control procedure 1. If 2. update 3. pass token bucket parameters , to the traffic policing module OPLab, IM, NTU

  20. Simulation result • Assumptions: (1) there are only two types of traffic (rtPS and BE) (2) all traffic is already admitted to the network (3) BE traffic requires uplink bandwidth at all times (4) (5) Frame size ( f ) = 10 ms (6) Input traffic: - three rtPS sessions with average total bandwidth ( ) of 3 Mbps - rtPS traffic characteristics are shown in Table I OPLab, IM, NTU

  21. Simulation result (cont’) OPLab, IM, NTU

  22. Simulation result (cont’) OPLab, IM, NTU

  23. Simulation result 2 “Performance Analysis of the IEEE 802.16 Wireless Metropolitan Area Network” Dong-Hoon Cho, Jung-Hoon Song, Min-Su Kim, and Ki-Jun Han Deartment of Computer Engineering, Kyungpook National University, Korea Proceedings of the First International Conference on Distributed Frameworks for Multimedia Applications (DFMA’ 05), IEEE Computer Society OPLab, IM, NTU

  24. Simulation result 2 (cont’) • Assumptions: - the effects of propagation delay are neglected - the channel is error-free - the BS has the ability to detect collision - each SS is assumed to be a Poisson traffic source OPLab, IM, NTU

  25. Simulation result (cont’) (a) Channel utilization when there is no limit of the bandwidth that the highest priority traffic can take (b) Channel utilization when only a fixed quota is allowed for the UGS flow Fig. 5. Channel Utilization OPLab, IM, NTU

  26. Simulation result (cont’) (c) Channel utilization of UGS flows (analytical and simulation results) (d) Channel utilization of rtPS flows(analytical and simulation results) Fig. 5. Channel Utilization OPLab, IM, NTU

  27. Simulation result (cont’) (f) Channel utilization of BE flows (analytical and Simulation results) (e) Channel utilization of nrtPS flows (analytical and simulation results) Fig. 5. Channel Utilization OPLab, IM, NTU

  28. Simulation result (cont’) (b) when average packet size = 150byte (a) when average packet size = 100byte Fig. 6. Throughput with different packet sizes OPLab, IM, NTU

  29. Simulation result (cont’) (c) when average packet size = 160byte (d) when average packet size = 200byte Fig. 6. Throughput with different packet sizes OPLab, IM, NTU

  30. Simulation result (cont’) (a) nrtPS flows (b) BE flows Fig. 7. Throughput for the nrtPS and the BE flows with different lengths of the contention period OPLab, IM, NTU

  31. conclusion • presented a scheduling algorithm and admission controlpolicy for IEEE 802.16 • the proposed solution provides QoS support in terms of bandwidth and delay bounds for all types of traffic classes as defined by the standard OPLab, IM, NTU

  32. Thanks for your listening OPLab, IM, NTU

  33. OPLab, IM, NTU

  34. OPLab, IM, NTU

  35. The frame in which the packet have to receive service to avoid the delay violation OPLab, IM, NTU

  36. Theorem 1 • Assumptions: 1. there are n rtPS connections with traffic parameters: token bucket rate ( ) in bps, token bucket size ( ) in bits, and delay requirement ( ) in seconds. 2. 3. OPLab, IM, NTU

  37. Theorem 1 (cont’) Case1: OPLab, IM, NTU

  38. Theorem 1 (cont’) For the general case OPLab, IM, NTU

  39. OPLab, IM, NTU

  40. Leaky bucket algorithm • The outflow is at a constant rate, ρ, when there is any water in the bucket andzero when the bucket is empty. • Once the bucket is full, any additional water entering it spills over the sides and is lost A leaky bucket with water OPLab, IM, NTU

  41. Leaky bucket algorithm (cont’) • each host computer is connected to the network by an interface containing a leaky bucket, that is, a finite internal queue • if a packet arrives at the queue when it is full, the packet is discarded • This mechanism turns an uneven flow of packets from the user processes inside the host into an even flow of packets onto the network Data Regulator  A leaky bucket with packets OPLab, IM, NTU

  42. Leaky bucket algorithm (cont’) • Smoothing out bursts and greatly reducing the chances of congestion • It is often better to allow a fixed number of bytes per tick, rather than just one packet. (byte-conunting leaky bucket) OPLab, IM, NTU

  43. Token bucket algorithm • It is better to allow the output to speed up somewhat when large bursts arrive. • The token bucket algorithm does allow saving, up to the maximum size of the bucket, b. • This property allows some burstiness in the output stream and gives faster response to sudden bursts of input. OPLab, IM, NTU

  44. Token bucket algorithm (cont’)  b : the token bucket capacity (bytes) ρ: the token arrival rate (bytes/sec) Token bucket Data Buffer  peak  Regulator avg   >  > peak avg The token bucket OPLab, IM, NTU

  45. Token bucket algorithm (cont’) • The length of the maximum rate burst: S : the burst length (sec) b : the token bucket capacity (bytes) ρ: the token arrival rate (bytes/sec) M : the maximum output rate (bytes/sec) the output burst contains a maximum of b + ρSbytes the number of bytes in a maximum-speed burst of length S second is MS • b+ ρS = MS • S= b / (M-ρ) OPLab, IM, NTU

  46. Token bucket algorithm (cont’) • capacity = 1 MB, b = 500 KB, ρ = 2 MB/sec, M = 25 MB/sec • S = b / (M-ρ) = 500KB / (25MB/sec – 2MB/sec) ≒ 22 msec Input output OPLab, IM, NTU

  47. Token bucket Leaky bucket Data Buffer Regulator Token bucket algorithm (cont’) • A potential problem with the token bucket algorithm is that it allows large bursts again • One way to get smoother traffic is to insert a leaky bucket after the token bucket. OPLab, IM, NTU

  48. Token bucket algorithm (cont’) capacity = 1 MB, b = 500 KB, ρ = 2 MB/sec, M = 10 MB/sec OPLab, IM, NTU

  49. References: - Andrew S. Tanenbaum, “Computer Networks”, 4th Edition. - Prof. Nalini Venkatasubramanian, Information and Computer Sciences, University of California, Irvine, “Lectures 13 - Multimedia Networking - Traffic Shaping and Rate Control” OPLab, IM, NTU

More Related