An Efficient Scheduling Algorithm for QoS Provisioning in WiMAX Networks

Maode Ma, Pengfei Xie, Sanjay Kumar Bose and Stephane Maag
support VoIP (Voice over IP) traffic in both UGS and rtPS (real-time Polling Service) in order to improve the utilization of the uplink bandwidth. In [8], a hierarchical scheduling algorithm was proposed to enhance the nrtPS (non real-time Polling Service) which could combine the rtPS and nrtPS together under a general polling framework. The proposed algorithm in [9] has considered detail scheduling issues to ensure the implementation of QoS differentiation. It implemented an overall scheduling policy for all the four traffic types. The proposed algorithm is a connection based algorithm and strict priority has been assigned to the four types. The solution employs the earliest deadline first (EDF) policy for rtPS connections and the weighted fair queue (WFQ) policy for nrtPS. However, the strict priority assignment of the four types of traffic makes the scheduling scheme lack of flexibility. For example, there is no chance for BE traffic, which has been delayed a long time until all the rtPS and nrtPS flows have all been serviced. This algorithm also requires rtPS traffic flows to delay in the network until the last time frame before deadline. Though this helps to reduce the possibility of starvation of bandwidth resources by high priority traffic, it underestimates the burst nature of rtPS traffic and results in high packets loss rate when the total burst traffic rate is more than the system capacity. In this paper, a novel connection oriented scheduling algorithm is proposed by introducing the new concept of urgency index (UI). UI is set of connection parameter monitored by the system to describe connections scheduling priority. The proposed solution breaks the strict priority assignments to different traffic types. By introducing proper UI changing profiles for each traffic type, it can effectively accommodate all the four traffic types. Simulation shows network performance of mean delay at low traffic loads and overall packets loss rate can be significantly enhanced. The main contribution of this paper is the new UI concept in WiMAX traffic scheduling to break rigid service priority and thus providing efficient QoS support. The remaining parts of this paper are organized as follows. Section 2 describes the WiMAX network system specifications and service types defined in standards; Section 3 describes the proposed UI based scheduling algorithm; Section 4 specifies the simulation system parameters and presents the simulation results; and Section 5 concludes the paper with a brief summary. II. SYSTEM SPECIFICATIONS A. System background The standard specifies the medium access control layer

AbstractThe advantages of high access speed and differentiated service provisioning with WiMAX technology has made it competent with current wired networks solutions. The various service types have been defined in recent 802.16 standards. However, the detailed traffic scheduling algorithm has been left empty to researchers. In this paper, the new concept of urgency index (UI) is brought out as the system parameter to monitor different traffic services. UI is a set of system variables to reflect the urgency of bandwidth need for a specific service flow. Traffic scheduling is done based on the UI values. For different types of services, different UI changing profiles have been proposed to achieve best scheduling outcome. This scheme was implemented and simulation results have been compared to other proposed scheduling algorithms to evaluate its performance. The results show the UI based scheduling algorithm can achieve lower packets drop rate and also lower mean delay time at all traffic loads.

I. INTRODUCTION WiMAX (Worldwide Interoperability for Microwave Access) networks are the new generation of wireless networks which could support real-time multimedia services. It has received much attention from the industry past a few years. The main advantage of WiMAX networks are high throughput, and long range of access distance. WiMAX access technology is defined in the IEEE 802.16 standards. It could provide support to various types of traffic, such as multimedia streaming and internet data traffic [1]. In the standards four types of traffic are defined, and an important issue in WiMAX networks is to provide QoS (quality of service) among the traffic services to meet delay time requirements. In order to achieve QoS support and efficient usage of system resources, intelligent traffic scheduling algorithms are required. The recent IEEE 802.16d standard which was published in 2004 has proposed a framework for service provisioning among the four traffic types. However, the detailed scheduling algorithm is left to the service providers and researchers. This leaves wide space for researchers to design and evaluate various traffic scheduling algorithms, and recently quite a few research papers have been published on QoS support in WiMAX networks. Most of the published works focus on the improvements of the QoS provisioning framework [2-5]. Some other proposals aimed to improve some issues in QoS support. As in [6], a synchronization scheme has been introduced to reduce the system overhead in UGS (Unsolicited Granted Service). In [7], it was suggested to
Maode Ma, Pengfei Xie, and Sanjay Kumar Bose are with the School of Electrical & Electronic Engineering, Nanyang Technological University, Singapore, 639798 (Maode Ma is the corresponding author with phone: 65-6790-4385, e-mail: emdma@ntu.edu.sg). Stephane Maag is with the Telecom & Management SudParis, France (e-mail: Stephane.Maag@it_sudparis.eu).

978-1-4244-2858-8/08/$25.00 2008 IEEE

(MAC) supports a primarily point to multipoint (PMP) architecture. The MAC is structured to support various physical layer (PHY) specifications, each suited to a particular operational environment. For the common operational frequencies of 10-66GHz, the WirelessMAN-SC PHY, based on single-carrier modulation is specified. For frequencies below 11GHz, propagation without a direct line of sight must be accommodated, and alternative PHY like WirelessMAN-OFDM should be used. The wide spectrum of 10-66GHz gives the system much bandwidth resources to operate with. Baud rates and channel bandwidths are specified in the standards. With different modulation techniques, WiMAX networks can achieve data transmission rates around 40 Mbps for each 25MHz bandwidth. There are also detailed recommendations for the PHY frame durations. The standards also specify QoS provisioning framework in the MAC layer. Downlink traffic is relatively simple because the BS (Base Station) broadcast messages to all the SS (Subscriber Station). For uplink traffic, request and grant scheduling is performed by BS with the intent of providing each SS with bandwidth for uplink transmission and opportunities to send bandwidth request. The uplink and downlink traffic can be multiplexed either with Time Division Duplex (TDD) or Frequency Division Duplex (FDD). The system under study of this paper is using the TDD mode. For TDD mode, the uplink and downlink transmissions occur at different times and share the same frequency. A TDD frame has fixed duration and is divided into subframes for uplink and downlink traffic. The frame is divided into an integer number of physical slots (PS), which is used as the bandwidth unit in scheduling. After BS has done the scheduling, the DL-MAP and UL-MAP fields which tell the scheduling results will be included in the downlink subframe. This information will be broadcasted to all the SS, so that each SS knows the bandwidth allocation results for the coming uplink subframe. B. Traffic types support Multiple types of traffic can be supported in WiMAX networks. There are four types of services specified in the standard. They are Unsolicited Grant Service (UGS), Real-time Polling Service (rtPS), Non Real-time Polling Service (nrtPS), and Best Effort (BE) service. These services have different QoS requirements and represent different types of network traffic. A good example for UGS traffic is VoIP, with fixed size packets stream and periodic inter-arrival time. This type of service eliminates the overhead and latency of SS requests and assures that grants are available to meet the flows real-time needs. The rtPS traffic is characterized by variable packet size and fixed inter-arrival time, such as video streaming traffic. The service offers real-time, periodic, unicast request opportunities, which meet the flows real-time needs and allow the SS to specify the size of the desired bandwidth grant. This service requires more requests overhead, but can support variable grant size to achieve optimum data transmission efficiency. The nrtPS offers unicast polls on a regular basis, which assures that the service

flow receives request opportunities even during network congestion. The SS can use both unicast request opportunities and contention based request opportunities. This service represents non real-time traffic which requires a minimum bandwidth allocation, such as bandwidth intensive file transfers. The intent of the BE service is to provide efficient data transmission for best effort traffic. For this service, SS is only allowed to use contention based request opportunities. This service represents time insensitive burst type traffic like internet data traffic. There is no QoS guarantee for BE service. C. Traffic scheduling The system works on a request-grant scheduling framework. The SS register its traffic connections with the BS, and send out traffic requests based on service specifications. The BS performs scheduling and broadcast the bandwidth allocations results to all SS. For contention based bandwidth request messages, the sending mechanism at SS follows a mandatory binary exponential backoff mechanism for contention resolution. There are some related parameters like initial window size and maximum windows size is configurable by the BS for different network systems. The detailed contention resolution mechanism can be found in [1]. The scheduler at BS takes account of all the connection specifications and request messages to perform the scheduling. Important parameters which the scheduler should consider include 1) the traffic service type; 2) the set of QoS requirements of the connections; 3) the capacity of bandwidth for data transmission; 4) the bandwidth requirements from the connections; and 5) waiting time of bandwidth requests in the system. The ideal scheduler should be able to make optimum use of the available bandwidth to reduce traffic delays and satisfy the QoS requirements to the best extent thus to reduce packets drop rate and sustain the QoS support. III. PROPOSED UI BASED SCHEDULING ALGORITHM A. The UI Concept In order to provide service to all the four types of service flows, its necessary to differentiate each service type and connection flow. Each service type has different QoS requirements and traffic characteristics. The traffic burst time is also different for each service flow. For the QoS scheduler to work effectively, the usage of Urgency Index (UI) is proposed as the only parameter set used in the scheduling scheme. Basically, the UI is set of variables which reflect the bandwidth requirement urgency of a specific connection. Since the MAC protocol is connection oriented, SS nodes request bandwidth on a connection basis. For optimal system resource utilization, the traffic allocation at BS is also to connections. With this scheme, the BS allocates bandwidth on a connection basis. The UI values represent traffic allocation priority. This scheme breaks the rigid priority assignment of the four service classes, and considers more parameters rather than the service type only. The contributing factors to the UI

values should include 1) Service type 2) Delay Bound 3) Waiting time of requested traffic. 4) Connection mean traffic rate. B. Index changing profile The UI value describes allocation priority of request from some connection. As an example, SS node m requests bandwidth Si bytes for connection CID i. Upon receiving the request message, BS denotes the request amount, and assigns a starting UI value u 0 to this connections traffic request. Then at each scheduling instant, the UI value is updated according to how long the traffic request has waited in the system; traffic allocation decisions will be made based on the new value. Since UI value essentially represents priority, it should be increasing by waiting time. On the other hand, its necessary to have a limiting value ul for the UI value to converge to. This limiting value represents priority of a connection in the long run if the request waits too long, and this value ul should represent the service type priority of connection. The scale of UI values can be arbitrary. For proper representation of priority of traffic needs, the UI values are limited to be normalized within 0.0 to 1.0, with 0.0 being least urgent, and 1.0 being most urgent. The UI value of a connections request needs to be re-initialized periodically. It will appear when 1) the requested amount Si is fully serviced and a new request Sj comes; or 2) the requested Si has waited too long and misses deadline for sure, and upon receiving a new request message, the UI value is reset to u 0 and starts a new period of change. The time unit in scheduling process should be carefully chosen for optimal bandwidth allocation results. Since scheduling is done at beginning of a time frame, let the time variable x be number of frames the connections request has waited in system since request been denoted. For the purpose of clear presentation, the frame duration is denoted as t f . The UI values should be a joint function of time variable x, service type T, delay bound D , mean traffic rate R, starting UI value u 0 and limiting UI value ul , with x being from 1 to . The UI profile can be formulated as below:
UI = fn( x, T , D, R, u0 , ul ), x = 1, 0.0 UI 1.0

guarantees allocation to UGS connections. The choice of Logarithm curve represents the highest priority assigned to UGS service, as characteristic of logarithm curve is very high rate of increasing at beginning, which means shorter time for UI value to reach ul . Since the packet size P is fixed for UGS connections, Ti can be readily calculated from R. Expressed into formula, the UI changing profile for UGS can be formulated as below:
UI UGS u l u0 ln( x ) + ul , for x = 1Ti / t f , = ln(Ti / t 0 ) u , for x > T / t i f l

(2)

where Ti=P/R is the packet inter-arrival time of UGS connection i. 2) UI Changing Profile for rtPS connections The bandwidth allocation between rtPS and BE connections is the major optimization for efficient QoS provisioning. Bandwidth should be used for rtPS connections while at rtPS traffic burst time and used for BE services while rtPS traffic is below mean rate. To achieve this, UI profiles for these two services have overlap region. The UI changing curve shape is important to describe service type priority characteristics. For rtPS traffic, the UI profile is proposed to be a liner relation with time index number x and changing from u 0 to

ul within half of the delay bound D of the connection flow.

Expressed in formula, it is:
u u0 ul u 0 , for x = 1( D / 2t f 1) x + u0 l D = D 2 2 2t f 2t f u l , for x D / 2t f

(3)

UI rtPS

(1)

1) UI changing profile for UGS connections The Standards specify UGS connections receive bandwidth allocation periodically without need of request messages and based on perceived traffic requirements. This type of traffic has highest priority and should be delayed in minimum level. Thus high values of u 0 and ul are desired. There are no request message needs for UGS connections, and the bandwidth requirement is denoted based on registered mean traffic rate. The UI changing curve is proposed to be a logarithm curve for UGS connections, and changing from u 0 to

The choice of a linear relation for the curve shape is to reflect the lower priority of rtPS service compared to UGS. Linear curve means constant increasing rate, which implies less aggressive bandwidth competition. 3) UI Changing Profile for BE connections For BE traffic, the UI profile is proposed to be an exponential curve. The characteristic of exponential curve is slow increase at beginning and fast in the end, which aims to limit the BE traffic to have low priority at the beginning, and gives bandwidth resources for higher priority service classes. Due to the fact BE connections are not guaranteed any QoS support, and the delay tolerance is generally long, the changing time taken for UI value to change from u 0 to ul is a configurable scheduler parameter for system objectives. Let this UI changing time of BE service be denoted as t r . This parameter essentially determines whats the level of expected BE connections delay time. The UI changing profile for BE connections can be expressed into formula as: t /t c ul u 0 t x e (u l u 0 ), for x = 1 r (4) exp( ) + u l
r f 0

UI BE

1 tr c0 = t f c0 e e c0 u l , for x > t r / t f

tr t f c0

e c0

tf

ul across the packet inter-arrival time Ti. This gives

The constant

c0 is chosen to be a suitable integer to make the

enough time for scheduler to allocate this traffic demand and

argument of exponential function bounded. The choice of

c0 should satisfy t r /(t 0 c0 ) 5 to best reflect the

exponential increasing profile. C. Scheduler Structure The scheduler is executed at the beginning of a time frame, and the first task is performed by the information module. The information module basically collects and stores the request messages from the SS. Then it performs necessary updates to the UI values and bandwidth requirements for each connection. For each time frame, the request messages will be received during the uplink subframe. These messages will be collected by the information module and stored in request messages queues. After noting down the traffic requirements, UI values for those active connections will be updated by the information module according to the UI profile formulas. Then the new UI values are calculated and updated in the database modules. The database module contains all the information required for the scheduling algorithm. Basically the database is updated by the information module and retrieved by the bandwidth assignment module. Bandwidth assignment module task is performed right after the Information module. It performs two major tasks in the scheduling algorithm. First it allocates time slots for SS which should have unicast request opportunities and also allocate contention based request opportunities to SS. Second, it allocates the uplink bandwidth available to SS based on the UI values in the database module. After obtaining the scheduling result, the request opportunities allocation and SS data burst size information is included in UL-Map messages, and the UL-Map messages are broadcasted to all SS. D. Scheduling at Subscriber Stations The UL-Map messages can only tell a specific SS the aggregate burst size the SS can use for current frame, but the SS would not know the scheduling results of per connection bandwidth allocation at BS side. For the proposed scheduling scheme to work properly, its necessary to include scheduler at each SS. The procedure of the scheduler in SS is exactly the same as in BS, and the scheduler handles fewer connections at each SS. The SS side scheduler performs allocation of the total burst size to its active connections in the way assumed by the BS traffic scheduler. The scheduler at SS should also perform bandwidth allocation based on UI values in synchronization with the BS. For bandwidth request messages, the sending mechanism is simple in this scheme. The request message only contains the connection queue size information and packet headers. For BE connections, the request messages sending follows the binary exponential backoff contention resolution process. Besides, BE connections would not try to request traffic and enter the contention process until the last bandwidth request has been fully serviced or request packet is lost.

IV. EXPERIMENTAL EVALUATION A. Simulation setup The PMP WiMAX network was implemented with C++ code with a discrete event simulation toolkit OMNet++. The system is configured to have one BS and seven SS. For each SS there are three types of traffic (UGS, rtPS, and BE), with each service type having adjustable number of connections. The UGS connections are taken as conventional VoIP traffic without silence suppression. The traffic rate for each connection is 83Kbits/s with delay bound of 60ms. For rtPS traffic, real video streaming traffic was used. The frame trace files were obtained from [10]. The traffic specifications can be found in Table 1. For the BE traffic, the traffic rate is adjustable and follows Poisson arrival distribution, and the packet size distribution is taken as the same as in [11].
Table 1. Specifications of the VoIP and Video Traffic
TSPEC Mean data rate (Kbps) Peak data rate (Kbps) Delay bound (ms) Mean packet size (bytes) Maximum packet size (bytes) VoIP (G.711 voice) 83 83 60 208 208 Video (H.263, Susi Und Strolch) 200 2500 40 979 12510 Video (H.263, Aladdin) 280 3500 40 1375 17444 Video (H.263, Mr Bean) 300 3200 40 1521 16221

For PHY specifications, the default system profile for 25MHz was used. With such a configuration, the total capacity of the network is 40Mbit/s. Each time frame size is configured to be 1ms as recommended in the standards for PMP operation. For ease of implementation, the time frame is assumed to be equally divided into two subframes. Uplink bandwidth is then exactly half of the total capacity. Extensive simulation work was carried out to examine the effectiveness of the proposed scheduler. The scheduler proposed in [9] was also implemented with OMNet++. It is taken as a benchmark and named as REF scheduler. Let the scheduler proposed in this paper be named as UI scheduler. For each simulation run, the mean delay time for all the traffic types are examined, and the packet loss rate for UGS and rtPS are also examined. B. Experimental results The average delay time is one of the most important factors to reflect the performance of the system. The overall average delay for the proposed UI scheduler is always lower than the REF scheduler. There is an up surge of the delay time when traffic load reaches 0.9. This is due to the burst nature of BE traffic and the fact full system capacity is almost reached. From the overall delay time distribution, the UI scheduler is generally better than the REF scheduler at all traffic loads. The average delay for each type of service is also studied. Figure 1 shows the average delay results for UGS traffic. UGS traffic has strict delay bound requirements and the BS grants bandwidth to UGS connections periodically. The UGS delay time is generally constant at all traffic loads. The

proposed UI Scheduler has a better performance on UGS delay. The UGS delay is cut down about 1/3 compared to the REF Scheduler. It shows the proposed scheduler makes efficient use of bandwidth and avoids unnecessary wait time in the system.

UGS connections is generally low and high priority is assigned to this traffic type.

Figure 3. rtPS drop rate results against traffic load Figure 1. UGS average delay results against traffic load

Figure 2 shows the average delay results for rtPS traffic. It can be seen that UI scheduler performs much better for rtPS traffic. The delay time is only about half in average. This is because in REF scheduler, rtPS traffic is kept in the system until the last time frame before deadline comes. There is no such limitation in the proposed UI scheduler. Another observation is that the delay time for REF scheduler is constant for all traffic loads, but for UI scheduler the delay time is rising slowly as traffic load increases. This also shows the flexibility of the UI scheduler, as it will try to service the rtPS connections as soon as possible when the system is not congested, but will delay them first for other traffic when the traffic load is high.

The drop rate for different traffic load for rtPS traffic is shown in Figure 3. It can be seen that UI scheduler performs much better than the REF scheduler. At low traffic load, the UI scheduler can achieve almost zero drop rates, but the REF scheduler can never reach below 0.1%. This is mainly because the REF scheduler keeps the rtPS traffic in system until the deadline comes, but this underestimates the burst nature of the rtPS traffic type. When the total burst rate exceeds the system capacity, drop of packets is unavoidable. The UI scheduler makes use of available bandwidth to service the arrived packets as much as possible within the delay bound. This gives longer period for scheduler to respond to traffic congestion and improves scheduler flexibility. In this way, it is able to meet the QoS requirements and yield high bandwidth efficiency at same time. From the simulation results, it can be seen the proposed UI scheduler performs better in both aspects of average delay time and QoS support capability. V. CONCLUSION In this paper, a novel traffic scheduler for WiMAX networks has been proposed. This scheduler makes use of the newly proposed Urgency Index concept and breaks the strict priority assignments between various traffic types. It can ensure the QoS effectiveness of the scheduling and improve efficiency in allocating bandwidth resources to different traffic types. A simulation model of the UI scheduler has been built and simulation results were obtained to compare with benchmark scheduler proposed in [9]. The results show that the proposed scheduler in this paper outperforms in both aspects of delay time and QoS provisioning. The simulation results have verified that our proposed UI scheduler is capable to enhance performance of WiMAX networks. Further studies can be made to investigate the optimization of the changing profiles of UI used in scheduling to further enhance the scheduling algorithm.

Figure 2. rtPS average delay results against traffic load

From all the average delay plots presented, its obvious the UI scheduler efficiency is higher in terms of delay time. The important objective of QoS provisioning of the scheduler is also verified by analyzing the packets drop rates for UGS and rtPS traffic. For both schedulers, UGS traffic has zero drop rates at all traffic loads. The excellent QoS provisioning for UGS is determined by the nature of its service type. The traffic rate of

REFERENCES
IEEE 802.16-2004, IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems. Oct.1. 2004 [2] M. Hawa, and D.W. Peter, Quality of Service Scheduling in Cable and Broadband Wireless Access Systems, Proceedings of 10th IEEE International Workshop on Quality of Service 2002, May 2002, pp. 247-255. [3] D.H.Cho, J. H. Song, M. S. Kim, K.J.Han, Performance Analysis of the IEEE 802.16 Wireless Metropolitan Area Network, Proceedings of the First International Conference on Distributed Frameworks for Multimedia Applications 2005 (DFMA 05), Feb. 2005, pp. 130-137. [4] H. S. Alavi, M. Mojdeh, and N. Yazdani, A Quality of Service Architecture for IEEE 802.16 Standards, Proceedings of Asia-Pacific Conference on Communications 2005, Oct. 2005, pp. 249- 253. [5] N. Liu, X. Li, C. Pei, and B. Yang, Delay Character of a Novel Architecture for IEEE 802.16 Systems, Proceedings of the Sixth International Conference on Parallel and Distributed Computing. Applications and Technologies 2005. Dec. 2005, pp293-296. [6] Y. Yao and J. Sun, Study of UGS grant synchronization for 802.16, Proceedings of the Ninth International Symposium on Consumer Electronics 2005, June 2005, pp.105-110. [7] H. Lee, T. Kwon, and D. H. Cho, An Enhanced Uplink Scheduling Algorithm Based on Voice Activity for VoIP Services in IEEE 802.16d Systems, IEEE Communication Letters. Vol. 9, Issue 8, Aug. 2005, pp. 691-693. [8] M. Ma and B. C. Ng, Supporting Differentiated Services in Wireless Access Networks, Communication systems, 2006. ICCS 2006. Oct. 2006, pp. 1-5. [9] K. Wongthavarawat and A. Ganz, Packet Scheduling for QoS Support in IEEE 802.16 Broadband Wireless Access Systems, International Journal of Communication Systems, Vol 16, No. 1, Feb. 2003, pp. 81-96. [10] MPEG-4 and H.263 Video Traces for Network Performance Evaluation, http://trace.eas.asu.edu/TRACE/trace.html [11] A. Grilo, M. Macedo, and M. Nunes, A Scheduling Algorithm for QoS Support in IEEE802.11E networks, Proceedings of the IEEE Wireless Communications 2003. June 2003, pp. 36-43 [1]