1 / 43

A Cross-Layer Scheduling Algorithm With QoS Support in Wireless Networks

A Cross-Layer Scheduling Algorithm With QoS Support in Wireless Networks. Qingwen Liu, Student Member, IEEE Xin Wang, Member, IEEE, Georgios B. Giannakis, Fellow, IEEE. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 55, NO. 3, MAY 2006. Presented by Jason, Li-Yi Lin. Outline. Introduction

Download Presentation

A Cross-Layer Scheduling Algorithm With QoS Support in Wireless 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. A Cross-Layer Scheduling Algorithm With QoS Support in Wireless Networks Qingwen Liu, Student Member, IEEE Xin Wang, Member, IEEE, Georgios B. Giannakis, Fellow, IEEE IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 55, NO. 3, MAY 2006 Presented by Jason, Li-Yi Lin NTU, IM, OPLab

  2. Outline • Introduction • System Architecture • Scheduler Design • Simulations • Conclusion and Future Directions NTU, IM, OPLab

  3. Introduction • Scheduling plays an important role in providing QoS support to multimedia communications in various kinds of wireless networks. • However many wireless standards define only QoS architecture and signaling, but do not specify the scheduling algorithm that will ultimately provide QoS support • Introduce a priority-based scheduler at the MAC layer for multiple connections with diverse QoS requirements, where each connection employs adaptive modulation and coding (AMC) scheme at the PHY layer. NTU, IM, OPLab

  4. Outline • Introduction • System Architecture - A. Network Configuration - B. QoS Architecture at the MAC - C. AMC Design at the PHY • Scheduler Design • Simulations • Conclusion and Future Directions NTU, IM, OPLab

  5. System Architecture – Network Configuration (1/6) NTU, IM, OPLab

  6. System Architecture – Network Configuration (2/6) • All connections communicate with the BS using TDM / TDMA • At the PHY, multiple transmission modes are available to each user, with each mode representing a pair of a specific modulation format and a forward error control (FEC) code • The AMC selector determines the modulation-coding pair, whose index is sent back to the transmitter through a feedback channel. NTU, IM, OPLab

  7. System Architecture – Network Configuration (3/6) SS BS NTU, IM, OPLab

  8. System Architecture – Network Configuration (4/6) • Transmission modes (TM): NTU, IM, OPLab

  9. System Architecture – Network Configuration (5/6) • At the MAC, each packet contains a fixed number of bits , which include packet header, payload, and CRC bits. • At the PHY, each frame contains a fixed number of symbols , and the frame duration (in seconds) is constant. • With TDM, each frame is divided into time slots. Let each time slot contain a fixed number of symbols. • The time slots contain control information and pilots; the time slots convey data. NTU, IM, OPLab

  10. System Architecture – Network Configuration (6/6) MAC PHY symbols NTU, IM, OPLab

  11. System Architecture – QoS Architecture at the MAC (1/2) • Unsolicited grant service (UGS) - this service provides guarantees on throughput, latency, and jitter to the necessary levels as TDM services - the QoS metrics are the packet error rate (PER) and the service rate • Real-time polling service (rtPS) - provides guarantees on throughput and latency, but with greater tolerance on latency relative to UGS - the QoS metrics are the PER and the maximum delay (or the maximum delay for a given outage probability) NTU, IM, OPLab

  12. System Architecture – QoS Architecture at the MAC (2/2) • Nonreal-time polling service (nrtPS) - provides guarantees only in terms of throughput - the QoS metrics are the PER and the minimum reserved rate • Best effort (BE) service - provides no guarantees on delay or throughput - although no delay and rate is specified for BE connections, a prescribed PER should be maintained over wireless channels NTU, IM, OPLab

  13. System Architecture – AMC Design at the PHY (1/3) • Efficient bandwidth utilization for a prescribed PER performance at the PHY can be accomplished with AMC schemes • Each connection with rtPS, nrtPS, and BE services relies on AMC at the PHY. • The objective of AMC is to maximize the data rate by adjusting transmission modes to channel variations while maintaining a prescribed PER NTU, IM, OPLab

  14. System Architecture – AMC Design at the PHY (2/3) • Let denote the total number of transmission modes available ( for TM) • The boundary points are denoted as • To avoid deep-channel fades, no data are sent when which corresponds to the mode with rate bits/symbol NTU, IM, OPLab

  15. System Architecture – AMC Design at the PHY (3/3) • Approximate the PER expression in AWGN channels as • Set the region boundary for the transmission mode to be the minimum SNR required to guarantee NTU, IM, OPLab

  16. Outline • Introduction • System Architecture • Scheduler Design • Simulations • Conclusion and Future Directions NTU, IM, OPLab

  17. Scheduler Design (1/8)- Scheduling UGS Connections • The transmission mode could be selected in the initial service access phase to meet the average PER requirement • Then, the transmission mode is fixed during the whole service time • Denote the total time slots allocated to UGS connections as per frame. The residual time slots are NTU, IM, OPLab

  18. Scheduler Design (2/8)- Scheduling rtPS, nrtPS and BE connections • Each connection adopts AMC at the PHY • Given a prescribed PER , the SNR thresholds for connection are determined as described above by setting • The possible transmission rate (capacity) can be expressed as where NTU, IM, OPLab

  19. Scheduler Design (3/8)- Scheduling rtPS, nrtPS and BE connections • At the MAC, the scheduler simply allocates all time slots per frame to the connection where is the PRF for connection at time • If multiple connections have the same value , the scheduler will randomly select one of them with even opportunity NTU, IM, OPLab

  20. Scheduler Design (4/8)- Scheduling rtPS, nrtPS and BE connections • The PRF for a rtPS connection at time is defined as where is the rtPS-class coefficient and is the delay satisfaction indicator, which is defined as with denoting the guard time region ahead of the deadline , and denoting the longest packet waiting time NTU, IM, OPLab

  21. Scheduler Design (5/8)- Scheduling rtPS, nrtPS and BE connections • If , i.e., , the delay requirement is satisfied • If , i.e., , the packets of connection should be sent immediately to avoid packet drop due to delay outage 0 NTU, IM, OPLab

  22. Scheduler Design (6/8)- Scheduling rtPS, nrtPS and BE connections • Guarantee the minimum reserved rate to each nrtPS connection • If data of connection are always available in queue, the average transmission rate at time is estimated over a windows size as NTU, IM, OPLab

  23. Scheduler Design (7/8)- Scheduling rtPS, nrtPS and BE connections • The PRF for an nrtPS connection at time is defined as where is the nrtPS-class coefficient and NTU, IM, OPLab

  24. Scheduler Design (8/8)- Scheduling rtPS, nrtPS and BE connections • The PRF for a BE connection at time is defined as where is the BE-class coefficient • The role of and in (6), (9), and (11), respectively, is to provide different priorities for different QoS classes NTU, IM, OPLab

  25. Outline • Introduction • System Architecture • Scheduler Design • Simulations • Conclusion and Future Directions NTU, IM, OPLab

  26. Simulations (1/10) Assumptions: • A1: The wireless channel quality of each connection remains constant per frame, but is allowed to vary from frame to frame • A2: Perfect channel state information (CSI) is available at the receiver via training-based channel estimation. The corresponding transmission mode selection is fed back to the transmitter without error and latency. • A3: Error detection based on CRC is perfect. • A4: if a packet is received incorrectly after error detection, we declare packet loss. NTU, IM, OPLab

  27. Simulations (2/10) Channel Model: • The received SNR per frame is a random variable with a Gamma probability density function, i.e., where , is the Nakagami fading parameter • Finite-state Markov chain (FSMC) model NTU, IM, OPLab

  28. Simulations (3/10) Parameter Setting: • The frame length is ms • The packet length at the MAC is fixed to bits • For each rtPS connection , we assume that the arrival process to the queue is Bernoulli distributed with a given average rate and parameter The instantaneous arriving rate at time can be expressed as NTU, IM, OPLab

  29. Simulations (4/10) rtPS connection 1 rtPS connection 2 NTU, IM, OPLab

  30. Simulations (5/10) • The guard time is set to ms • The delay outage probability where window size ms NTU, IM, OPLab

  31. Simulations (6/10) • For each nrtPS connection , we assume that the data are always available nrtPS connection 3, 4 NTU, IM, OPLab

  32. Simulations (7/10) • For each BE connection , we assume that the data are always available • The rate performance of nrtPS and BE connections is also evaluated by the average service rate over a window size ms • The system is simulated over 60000 ms with bounds BE connection 5, 6 NTU, IM, OPLab

  33. Simulations (8/10) NTU, IM, OPLab

  34. Simulations (9/10) NTU, IM, OPLab

  35. Simulations (10/10) NTU, IM, OPLab

  36. Outline • Introduction • System Architecture • Scheduler Design • Simulations • Conclusion and Future Directions NTU, IM, OPLab

  37. Conclusion and Future Directions (1/3) • Efficient bandwidth utilization is achieved through in • Delay bound is provided for rtPS connections and we can control the delay outage probability below the practically acceptable values by adjusting • Throughput is guaranteed for nrtPS connections if sufficient bandwidth is provided NTU, IM, OPLab

  38. Conclusion and Future Directions (2/3) • Implementation complexity is low because the scheduler simply updates the priority of each connection per frame • Flexibility is provided because the scheduling does not depend on any traffic or channel model • Scalability is achieved. NTU, IM, OPLab

  39. Conclusion and Future Directions (3/3) Future Directions: • The upper-bound and the delay guard time were set heuristically, their effects on performance are worthy of further research • Scheduling multiple connections each time may lead to better performance • The fairness issue for the users in the same service class is another topic • The effects of imperfect channel state information due to estimation error and feedback latency are also worth further study NTU, IM, OPLab

  40. Thanks for your listening NTU, IM, OPLab

  41. Conclusion and Future Directions For rtPS For nrtPS For BE NTU, IM, OPLab

  42. Finite-state Markov chain (FSMC) model NTU, IM, OPLab

  43. Finite-state Markov chain (FSMC) model (cont’) NTU, IM, OPLab

More Related