490 likes | 498 Views
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.
E N D
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
Outline • Introduction - IEEE 802.16 broadband wireless access system - QoS Architecture • Proposed uplink packet scheduling • Admission control • Simulation results • Conclusion OPLab, IM, NTU
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
QoS Architecture OPLab, IM, NTU
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
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
Roposed uplink packet scheduling OPLab, IM, NTU
Roposed uplink packet scheduling (cont’) Signaling flow Proposed signaling flow Proposed module Data flow Proposed QoS architecture OPLab, IM, NTU
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
Information module (cont’) OPLab, IM, NTU
Information module (cont’) Assume current time is t, and the current frame is [t, t+f] OPLab, IM, NTU
Scheduling database module OPLab, IM, NTU
Scheduling database module (cont’) OPLab, IM, NTU
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
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
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
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
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
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
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
Simulation result (cont’) OPLab, IM, NTU
Simulation result (cont’) OPLab, IM, NTU
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
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
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
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
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
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
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
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
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
Thanks for your listening OPLab, IM, NTU
The frame in which the packet have to receive service to avoid the delay violation OPLab, IM, NTU
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
Theorem 1 (cont’) Case1: OPLab, IM, NTU
Theorem 1 (cont’) For the general case OPLab, IM, NTU
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
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
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
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
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
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
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
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
Token bucket algorithm (cont’) capacity = 1 MB, b = 500 KB, ρ = 2 MB/sec, M = 10 MB/sec OPLab, IM, NTU
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