Analysis of Quality of Service (QoS) in WiMAX networks

Rohit A. Talwalkar*, Mohammad Ilyas**, * Motorola Inc,8000 West Sunrise Blvd, FL 33322 USA (e-mail: rtalwalkar@gmail.com).
**Associate Dean for Research and Industry Relations at the College of Engineering and Computer Science, Florida Atlantic University, Boca Raton, FL 33431 USA. (e-mail: ilyas@fau.edu).

Abstract In last few years there has been significant growth in the area of wireless communication. Quality of Service (QoS) has become an important consideration for supporting variety of applications that utilize the network resources. These applications include voice over IP, multimedia services, like, video streaming, video conferencing etc. IEEE 802.16/WiMAX is a new network which is designed with quality of service in mind. This paper focuses on analysis of quality of service as implemented by the WiMAX networks. First, it presents the details of the quality of service architecture in WiMAX network. In the analysis, a WiMAX module developed based on popular network simulator ns-2, is used. Various real life scenarios like voice call, video streaming are setup in the simulation environment. Parameters that indicate quality of service, such as, throughput, packet loss, average jitter and average delay, are analyzed for different types of service flows as defined in WiMAX. Results indicate that better quality of service is achieved by using service flows designed for specific applications. Index TermsIEEE 802.16, QoS, WiMAX

I. INTRODUCTION WIMAX stands for Worldwide Interoperability for Microwave Access. It is the technology aimed to provide broadband wireless data access over long distances. It is based on Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard [1], [2]. The technology provides basic Internet Protocol (IP) connectivity to the user. The variety of applications used in IP networks has increased tremendously in the recent years. Various multimedia applications along with the common email, file transfer and web browsing applications are becoming increasingly popular. These applications send large audio and video streams with variable bandwidth and delay requirements. On the other hand, remote monitoring of critical services, electronic commerce and banking applications, as well as, network control and signaling do not need strict bandwidth guarantees due to the bursty nature of the data transfer. Instead, these applications require reliable and prompt packet routing. The presence of

different kinds of applications in a network, results in heterogeneous traffic load. The traffic from different applications may require certain type of quality of service. In this paper, the Quality of Service (QoS) as prescribed in the WiMAX networks is studied. As packets travel within a wireless network such as WiMAX, they experience the following problems: Delay, jitter, out-of-order delivery, packet loss or error. There is no formal definition of Quality of service. QoS, in the field of telephony, was defined in 1994 in the International Telecommunication Union (ITU) Recommendation E.800. This definition is very broad, listing 6 primary components: Support, Operability, Accessibility, Retainability, Integrity and Security. In 1998, the ITU published a document discussing QoS in the field of data networking. The term Quality of Service refers to the probability of the telecommunication network meeting a given traffic contract. In the field of packet-switched networks and computer networking it is used informally to refer to the probability of a packet succeeding in passing between two points in the network. Although the name suggests that it is a qualitative measure of how reliable and consistent a network is, there are a number of parameters that can be used to measure it quantitatively. These include throughput, transmission delay or packet delay, delay jitter, percentage of packets lost etc. The IEEE 802.16 standard includes the QoS mechanism in the Medium Access Control (MAC) layer (layer 2) architecture. It defines service flows which can map to DiffServ[3] code points. This enables end-to-end IP based QoS. Among other things, the MAC layer is responsible for scheduling of bandwidth for different users. The MAC layer performs bandwidth allocation based on user requirements as well as their QoS profiles. The standard is designed to support a wide range of applications. These applications may require different levels of QoS. To accommodate these applications, the 802.16 standard has defined five service flow classes. These are summarized in Table 1. These service flows can be created, changed, or deleted by the issuing Dynamic Service Addition (DSA), Dynamic Service Change (DSC), and Dynamic Service Deletion (DSD) messages. Each of these actions can be initiated by the Subscriber Station (SS) or the Base Station (BS) and are ICON 2008

978-1-4244-3805-1/08/$25.00 2008IEEE

carried out through a two or three-way-handshake.

TABLE I SERVICE CLASSES DEFINED BY WIMAX Description Applications Unsolicited (UGS) For Constant Bit Rate dependent applications VOIP

Grant Service (CBR) and delay-

Real-Time Polling

For Variable Rate and delay dependent

Streaming audio, Streaming video

Service (rtPS) applications

Extended Real-Time Polling Service (ertPS)

For Variable Rate and delay dependent applications

VOIP with silence suppression

VOIP traffic and multimedia streaming traffic. The VOIP traffic is set up using five different VOIP codecs which have different packet size and data rates. The effect of number of nodes in the network requesting VOIP traffic is analyzed. The experiment is repeated for all the five VOIP codecs. The VOIP traffic is set up using the three supported service flows that are supported namely, best effort (BE), real-time polling service (rtPS) and unsolicited grant service (UGS). The effect of the service flow on the quality of service parameters such as throughput, average jitter and packet loss is studied. Next, the use case of streaming video is case is studied. The effect of number of nodes on the multimedia traffic is analyzed for different service flows. Similar to the case of VOIP traffic, the analysis is done based on the four QoS parameters namely, throughput, average jitter, average delay and packet loss. The results of the experiments are analyzed and conclusions are presented. II. BACKGROUND AND EXPERIMENTAL SETUP

Non-real-time Variable rate and nonPolling Service (nrtPS) Best Effort (BE) Best Effort real time applications

FTP

E-mail, web traffic

For example, a new service flow initiated by the SS is built as follows. When SS detects the emergence of a new service flow, it will calculate the available resources to determine whether a DSA request will be sent or not. Upon reception of the DSA request, the BS verifies whether this request can be supported, and sends a DSA response. Based on the DSA response, the SS sends a DSA acknowledgement and enables the new service flow if the request is approved. The standard provides some rules to classify DiffServ [3] IP packets into different priority queues based on IP QoS indication bits in IP header. This paper focuses on the analysis of QoS in WiMAX networks. The details of the implementation of QoS in the WiMAX network architecture will be presented. It includes the definition of various service flows defined by the IEEE 802.16 standard. The details of the networks MAC layer QoS implementation are presented. To analyze the QoS parameters simulation based on the popular network simulator ns-2 is used. Various parameters that determine QoS of real life usage scenarios and traffic flows of applications is analyzed. The goal is to compare different types of service flows with respect to the QoS parameters, such as, throughput, average jitter, average delay and packet loss. A WiMAX module written for ns-2[4][5] is used to simulate real life situations and analyze the effect of various network conditions and load on QoS parameters. The parameters considered are throughput, average jitter, percentage packet loss and average delay. Use cases simulated

A. WiMAX Network Architecture and MAC layer details The WiMAX End-to-End Network Systems Architecture document [6] defines the WiMAX Network Reference Model (NRM). It is a logical representation of the network architecture. The NRM identifies functional entities and reference points over which interoperability is achieved. The architecture has been developed with the objective of providing unified support of functionality needed in a range of network deployment models and usage scenarios. Figure 2 shows basic components of a WiMAX network. The SS are connected over the air interface to the BS. The base station is part of the Access Service Network (ASN) and connects to the Connectivity Service Network (CSN) through the ASN Gateway. In generic telecommunication terminology, ASN is equivalent to RAN (Radio Access Network) and CSN is equivalent to Core. B. MAC layer details in IEEE 802.16/WiMAX network The IEEE 802.16 MAC layer performs the standard Medium Access Control (MAC) layer function of providing a medium-independent interface to the physical (PHY) layer. WiMAX systems are based on Orthogonal Frequency Division Multiple Access (OFDMA). It provides improved multi-path performance and operation in non-line-of-sight environments. Scalable OFDMA (SOFDMA) is introduced in the IEEE 802.16e amendment to support scalable channel bandwidths. Some of the key features supported by WiMAX include the following. High Data Rates: Data rates of up to 63 Mbps in downlink and up to 39 Mbps in uplink can be achieved in WiMAX in a 10MHz channel. This is possible because of inclusion of MIMO (Multiple Input Multiple Output) antenna techniques along with flexible sub-channelization schemes, larger MAC frames, Advanced Coding and Modulation.

 Scalability: WiMAX technology is designed to be able to scale to work in different channelization from 1.25 to 20 MHz

Fig. 2. WiMAX Network IP-Based Architecture

to comply with varied worldwide requirements. This also deployment of WiMAX network in different geographical regions based on varying needs. Security: Another key feature of WiMAX networks is that the security layer is built into the protocol stack instead of being added on later. The security layer is sandwiched between PHY and MAC layers. The messages for authentication and key exchange are defined as part of the MAC layer. The MAC layer performs encryption based on the keys negotiated during the key exchange phase. Mobility: WiMAX supports optimized handover schemes with latencies less than 50 milliseconds to ensure real-time applications such as VoIP perform without service degradation. Flexible key management schemes assure that security is maintained during handover. QoS: Finally the fundamental premise of the IEEE 802.16 MAC architecture is QoS. The QoS architecture will be discussed in detail shortly. The main focus of the MAC layer is to manage the resources of the air-link in an efficient manner. MAC layer is responsible for overall connection and session processing. The MAC layers at BS and SS communicate to set up an RF connection, and to set up, add and delete services on an as needed basis. As mentioned earlier, the IEEE 802.16 standard has defined five service flow classes which have different QoS requirements: Unsolicited Grant Service (UGS), RealTime Polling Service (rtPS), non-Real-Time Polling Service (nrtPS), Enhanced-Real-Time Polling Service (ertPS), and best effort (BE). Each scheduling service is characterized by a mandatory set of QoS parameters, which is tailored to best describe the guarantees required by the applications that the scheduling service is designed for. Furthermore, for uplink connections, it also specifies which mechanisms to use in order to request bandwidth. UGS is designed to support real-time applications (with strict delay requirements) that generate fixed-size data packets at periodic intervals, such as T1/E1 and VoIP without silence suppression. The guaranteed service is defined so as to closely follow the

packet arrival pattern. Uplink grants are granted by the BS regardless of the current estimation of backlog; hence, UGS connections use the unsolicited granting bandwidth-request mechanism. Thus UGS connections never request bandwidth. It is given periodic bandwidth without any polling or contention. The grant size is computed by the BS based on the minimum reserved traffic rate, which is defined as the minimum amount of data transported on the connection when averaged over time. If additional bandwidth is required, the SS may request the BS to poll it to allocated bandwidth. rtPS is designed to support real-time applications (with less stringent delay requirements) that generate variable-size data packets at periodic intervals, such as Moving Pictures Expert Group (MPEG) video and VoIP with silence suppression. The key QoS parameters for rtPS connections are the minimum reserved traffic rate, which has the same meaning as with UGS, and the maximum latency, which upper bounds the waiting time of a packet at the MAC layer. Since the size of arriving packets with rtPS is not fixed, as it is with UGStailored applications, rtPS connections are required to notify the BS of their current bandwidth requirements. The BS periodically grants unicast polls to rtPS connections. The polling period may be explicitly specified as an optional QoS parameter, namely, the unsolicited polling interval. Unlike UGS and rtPS scheduling services, nrtPS and BE are designed for applications that do not have any specific delay requirement. The main difference between the two is that nrtPS connections are reserved a minimum amount of bandwidth (by means of the minimum reserved traffic rate parameter), which can boost performance of bandwidthintensive applications, such as File Transfer Protocol (FTP). Both nrtPS and BE uplink connections request bandwidth by either responding to broadcast polls from the BS or piggybacking a bandwidth request on an outgoing Packet Data Unit (PDU). These requests are contention based. C. Analysis Strategy To analyze QoS in a network it is necessary to study real life scenarios. The simulation set up would reflect the actual deployment of the WiMAX network. Based on the network reference model described earlier, Fig. 3 shows the setup that will be used. There are multiple SSs in the range of a base station. The base station is connected to the core network. The focus of analysis will be the connection between the subscriber and the base station. Various types of traffic can be set up from the subscriber station to mimic real life scenarios. For example, the subscriber can place a VOIP call.

Fig. 3: Simulation setup.

D. Simulation Details Different approaches were considered in the beginning of the work. An attempt was made to write an event driven simulation in C++. However, by that time, couple of WiMAX simulators became available in the pubic domain. These included the work by Chen et al [7] at Chang Gung University, Taiwan, available through their website [8]. The other available simulator was the WiMAX module written in a collaborative effort of Application Architecture Task Group (AATG), WiMAX Forum and National Institute of Standards and Technology (NIST) [5]. Both simulators were modules available to be used in conjunction with ns-2. The network simulator 2 (ns-2) [4] is a popular tool for the simulation of packet-switched networks. It provides substantial support for simulation of TCP, routing, and MAC protocols over wired and wireless networks. The simulator core is written in C++. It has an OTcl (Object Tool Command Language) interpreter shell as the user interface and allows input models written as Tcl (Tool Command Language) scripts to be executed. Most network elements in ns-2 simulator are developed as classes, in object-oriented fashion. It is freely distributed and all the source code is available. Figure 4 shows basic structure of ns-2. The network topology and traffic agents etc are specified in the TCL file. It is parsed by the oTCL interpreter. The C++ library has all the implementation details. When ns-2 is run, the resulting data could be obtained in a trace file format. The trace file contains time stamp and information about each packet that is sent, received or dropped. It also has information about the packet size, type of packet etc. A base station and a subscriber station can be set up as a node in ns-2. As the number of nodes in the simulation increase, the packets that are sent and received increases. This makes the trace file very large. To aide in extracting the right data out from the file, a PERL script was written, details of which are provided later.

both physical (PHY) and MAC layers based on IEEE 802.16e standard. After setting up ns-2 and compiling the WiMAX module it was discovered that there were several memory leaks in the simulation. For a single node the simulation would run properly but as the nodes increased, so would the packet traffic. This would eventually cause the simulation to stop to run as it would run out of dynamic memory necessary to allocate new packets. Several memory leak issues were fixed during the course of experimentation, to make the simulation useful. These issues and fixes were reported back to the WiMAX forum. As mentioned earlier, simulation scenario for ns-2 is defined by a Tcl script. This file contains all the information needed to run the simulation. In a typical model, the nodes in the network are setup, starting with the base station. The mobile nodes are created and associated with the base station they belong to at the start. A traffic agent is created and is attached to the source node. An example of a traffic agent could be a CBR traffic agent. On the top of the traffic agent, an application which generating required traffic created. There is a sink node created and attached to the base station using a wired connection. This sink node is just to accept the incoming packet. The focus of the study will be the path

Fig 5: NS-2 Simulation example

between the mobile node and the base station. After the simulation starts each node goes through basic registration procedure to get associated with the base station. So the traffic is started after some time to allow the mobile node to complete the registration. In the simulation, the traffic is started 15 seconds after the simulation is started. Fig. 5 displays a typical example of the ns-2 setup. In the WiMAX module, the mobile nodes are created as MAC/802_16/SS nodes and the base station is created as MAC/802_16/BS node. When the mobile node is added to the base station, using setflow command the service flow is statically created. The types of service flows that are supported by the version 2.1 of the WiMAX modules are, BE, rtPS and UGS. At this point, nrtPS and ertPS service flows are not supported. The TCL scripts were parameterized. The input

Fig 4: NS-2 Architecture and set up

In case of the Chang Gung University simulation, there was no concept of a base station for a particular node. However the WiMAX forum simulator had the distinction between nodes. While setting up the node, it could be classified as a base station as opposed to a subscriber node. Thus it was decided to use the simulator from WiMAX forum. Version 2.31 of ns-2 and Version 2.1 of the WiMAX module from NIST was used. The WiMAX module simulates

parameters that were varied, for example, number of nodes in the simulation, was passed in as a parameter while running the simulation for easy execution. E. QoS Parameters QoS provisioning encompasses providing Quality of Service to the end user in terms of several generic parameters. The perceived quality of service can be quantitatively measured in terms of several parameters. In the analysis, the throughput, average delay, average jitter and packet loss were considered. Throughput Throughput is a measure of the date rate (bits per second) generated by the application. Equation 1 shows the calculation for throughput TP, where PacketSizei is the packet size of the ith packet reaching the destination, PacketStarto is the time when the first packet left the source and PacketArrivaln is the time when the last packet arrived.
TP =

a network. Measuring jitter is critical element to determining the performance of network and the QoS the network offers. Equation 3 shows the steps for calculation of average jitter. It is the average of the absolute difference in the time it took for successive packets to reach the destination. i (PacketArrivali+1 PacketStarti+1 ) (PacketArrivali PacketStarti ) (3)
AverageJit = ter n 1

Packet loss or corruption rate Packet loss affects the perceived quality of the application. Several causes of packet loss or corruption would be bit errors in an erroneous wireless network or insufficient buffers due to network congestion when the channel becomes overloaded. Equation 4 shows the simple equation to calculate packet loss. It is the sum of all the packets that do not reach the destination over the sum of the packets that leave the destination

PacketLoss =

LostPacketSize PacketSize
j

100

(4)

PacketSize
i

A PERL script was written to analyze the ns-2 trace files and calculate the four parameters.

PacketArrival n PacketStart 0

(1) III. SIMULATION RESULTS To analyze the quality of service in WiMAX network, various real life use cases are considered. WiMAX provides basic IP connectivity. Mobile devices capable of using WiMAX network will need to support voice calling over the internet protocol. Thus, VOIP is the first application considered. With the availability of a larger data pipe, another common application these days is viewing videos over the internet. So video streaming is analyzed as well. In this section, the simulation results are presented. The QoS parameters, obtained for VOIP traffic, are presented first. The multimedia traffic results follow. A. VOIP Traffic A number of nodes are placed in the coverage area of the base station and VOIP traffic is attached to each node. The VOIP traffic is a CBR (Constant Bit Rate) flow with size of packet and packet rate governed by the codec. The following codecs were used G.711, G.729, G.729.2, G.723, G.723.2. For each of the codecs, number of nodes with the VOIP traffic was varied from 2, 4, 6, 8 and 10. This experiment was repeated for the following service flows which are defined by IEEE 802.16e standard: BE: Best Effort, rtPS: Real Time Polling Service, UGS- Unsolicited Grant Service. Note that simulation did not support ertPS (Enhanced Real Time Polling Service) and nrtPS (Non Real Time Polling Service). The results obtained are presented.

From the trace file, based on the packet ID, each data packet was kept track of. The time a packet is sent, the time when the packet was received and the packet size was stored for all packets that reached the destination. To calculate throughput, the size of each packet was added. This gave the total data that was transferred. The total time was calculated as the difference between the time the first packet started and the time the last packet reached the destination. Thus throughput is equal to the total data transferred divided by the total time it took for the transfer. Average Delay Delay or latency would be time taken by the packets to transverse from the source to the destination. The main sources of delay can be further categorized into: sourceprocessing delay, propagation delay, network delay and destination processing delay. Equation 2 show the calculation for Average Delay, where PacketArrivali is the time when packet i reaches the destination and PacketStarti is the time when packet i" leaves the source. n is the total number of packets.
AverageDelay =

PacketArrival
i

PacketStart i

(2)

Average Jitter Delay variation is the variation in the delay introduced by the components along the communication path. It is the variation in the time between packets arriving. Jitter is commonly used as an indicator of consistency and stability of

Fig 6 shows the behavior of throughput as the number of nodes increase. The highest throughput is observed for UGS
Throughput
600 500 400 UGS kb p s 300 200 100 0 2 4 6 Number of nodes 8 10 RTPS BE

Fig 6: Variation of Throughput for VOIP traffic Codec: G.711 ((64kbps): 80 bytes frame, 160 bytes payload, 50 pkts per sec.)

the BS polls the SS to send a bandwidth request. Hence, there are lot of control packets that go between the SS and the BS other than the actual data packets. This is the reason for increased packet loss. The packets loss is highest in case of BE traffic. As the number of nodes increases, each node starts sending packets some of which collide and as the traffic increases, for BE case, packets get dropped because of collision. Fig 8 shows the average jitter for all the three service flows. The graph is drawn on logarithmic scale to make the comparison easy. BE service flow has the highest jitter. The average jitter for UGS service flow does not vary as much as the number of nodes increases. Secondly the value is very small. UGS service flow is designed for VOIP traffic which generates periodic fixed sized packets. Jitter is one of the main parameters for indicating the perceived quality of voice as it reaches the destination node.
Average Jitter on Log Scale

service flow. This is expected behavior. The reason for this is that UGS flow has the least packet loss. With less number of packets lost, the average throughput is higher for UGS. The throughput for rtPS traffic and BE traffic is very similar. UGS service flow is designed with constant bit rate traffic in mind. Since a periodic bandwidth is allocated by the BS to the SS, the SS is able to send all the voice packets generated at a fixed interval. In rtPS service flow, the bandwidth allocation is done using polling. The BS polls the SS to send a bandwidth request. Fig 7 shows comparative graph for the three service flows as the packet loss changes when the number of nodes
Packet Loss
1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 2 4 6 Num ber of nodes 8 10 % UGS RTPS BE

1.00E+01 Log of Average Jitter 1.00E-01 1.00E-03 1.00E-05 1.00E-07 1.00E-09 1.00E-11 Number of Nodes 2 4 6 8 10 UGS RTPS BE

Fig 8: Variation of Average Jitter for VOIP traffic Codec: G.711 ((64kbps): 80 bytes frame, 160 bytes payload, 50 pkts per sec.)

Fig 9 shows average delay variation for the three service

Average Delay
0.000169 0.0001685 0.000168 seconds

UGS
0.0001675 0.000167 0.0001665 0.000166 2 4 6 Num ber of nodes 8 10

RTPS BE

Fig 7: Variation of Packet loss for VOIP traffic Codec: G.711 ((64kbps): 80 bytes frame, 160 bytes payload, 50 pkts per sec.)

increases. UGS service flow has the lowest packet loss. This expected behavior. UGS is designed to support real-time services that generate fixed sized data packets on a periodic basis. VOIP applications do exactly that. UGS offers fixedsize grants on a real-time periodic basis and does not need the SS to explicitly request bandwidth. The SS is already granted a fixed bandwidth and can transmit the data packets in a specific slot during the uplink transmission. Bandwidth is not requested regularly as in the case of rtPS service flow, where

Fig 9: Variation of Average Delay for VOIP traffic Codec: G.711 ((64kbps): 80 bytes frame, 160 bytes payload, 50 pkts per sec.)

flows. The values for UGS and rtPS flows fall very close to each other overlapping the two lines in the graph. The BE effort service flow has the higher delay as compared with UGS and rtPS flows.

In conclusion, it is observed that UGS service flow has the highest throughput, least packet loss and lowest average jitter. This makes it best suited for VOIP traffic. UGS service flow is designed to handle fixed sized packets generated a regular interval. The simulation results validate that.
%

Packet Loss
18 16 14 12 10 BE RTPS UGS

B. Video Traffic A number of nodes generating streaming video traffic are set up in this experiment. The performance of QoS service flows in terms of the QoS parameters was analyzed. Video streaming is a VBR traffic i.e. Variable Bit Rate. Unlike CBR the packet size is varies based on each frame type e.g. in case of a MPEG traffic, the I and B frames are smaller in size than a P frame Similarly for H.263 traffic, there are I frames, P frames and PB frames. For the analysis using the simulation, a 64kbps H.263 data stream was used. Along with video streaming, H.263 format is commonly used for or video-conferencing and video-telephony applications. The VBR frame stream for the H.263 encoded Jurassic Park movie was obtained from the following website in [9]. Using this information, a trace file is generated. This trace file is attached to the User Datagram Protocol (UDP) agent as a traffic source. The trace file is in binary format and contains information of the time and packet size. Analysis is done using BE, rtPS and UGS service flows for the video traffic. The parameters analyzed are throughput, packet loss, average jitter and average delay. These parameters are observed for each service flow as the number of nodes with the video traffic increases. The results obtained
Throughput

8 6 4 2 0 0 2 4 6
Number of Nodes

10

12

Fig 11: Variation of Packet Loss for Video Traffic Video Parameters: 64kbps H.263

nodes. The rtPS service flow has very high rate of packet loss as the number nodes increase. This is because of the bandwidth request mechanism used in rtPS service flows. There is a lot of overhead in requesting bandwidth from the base station. Fig 12 shows the variation of average jitter with all three service flows. To make the comparison easier a logarithmic scale is used. From the figure it shows that the jitter is very constant for UGS flow. However, rtPS flow has lower jitter than UGS service flow and it remains more or less constant. On the other hand, for single node, BE service flow has the lowest jitter. As the nodes increase, however, the jitter starts increasing. Thus when lot of network resources are available video traffic over BE service flow introduces the least jitter.
Average Jitter
1

700 600 500

Kbps

10

400 300 200 100 0 0 2 4 6

Number of Nodes

BE RTPS UGS

Log of Average Jitter

0.1 BE 0.01 RTPS UGS 0.001

10

12

0.0001 Number of nodes

Fig 10: Variation of Throughput for video traffic Video Parameters: 64kbps H.263

Fig 12: Variation of Average Jitter for video traffic Video Parameters: 64kbps H.263

are presented here. When the three service flows are compared on a single graph some interesting patterns can be observed. Fig 10 shows the variation of overall throughput for video traffic as the number of nodes increase. The overall throughput is marginally higher in case of UGS service flow. For 10 nodes, the rtPS throughput is the lowest. This can be explained in conjunction with Fig 11 which displays the packet loss. Fig 11 shows the variation of packet loss with number of

However, as the nodes increase, the network resources get divided between all the nodes. Thus, it can be concluded that, the from average jitter consideration, for video streaming traffic, rtPS service flow is best suited. When different video frames arrive at the recipient, it there is a lot of jitter, the video does not appear to run smoothly. Thus average jitter is indicative of quality for video streaming.

Fig 13 shows the average delay for the three service flows
Average Delay
0.014 0.012 0.01 0.008
ms

BE RTPS UGS

0.006 0.004 0.002 0 0 2 4 6

Number of Nodes

10

12

Fig 13: Variation of Average Delay for video traffic Video Parameters: 64kbps H.263

allocated by the BS to the SS. VOIP traffic generates fixed sized packets at a fixed interval. Thus the UGS service flow handles the traffic generated by VOIP calls in the most optimum way. The rtPS service flow is designed for applications such as streaming audio and streaming video. During the analysis of the video traffic, as the number of nodes increases, rtPS service flow comes out to be better than BE service flow for average jitter. UGS still has lower packet loss. However, UGS service flow does not utilize the network resources effectively when the traffic is not constant bit rate traffic. Streaming video traffic is variable bit rate traffic. The bandwidth can be periodically requested in the rtPS service flow instead of fixed bandwidth already being allocated, which may or may not get used. REFERENCES
IEEE 802.16-2004, IEEE standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems, Oct. 2004. [2] IEEE Std 802.16e-2005, "IEEE Standard for Local and metropolitan area networks--Part 16: Air Interface for Fixed Broadband Wireless Access Systems--Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands," Feb. 2006. [3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998 [4] The network simulatorns-2. http://www.isi.edu/nsnam/ns/ [5] NS-2 WiMAX Simulation Bundle, http://www.wimaxforum.org/members/ns2_simulator_evaluation/ [6] WiMAX End-to-End Network Systems Architecture - Stage 2: Architecture Tenets, Reference Model and Reference Points, WiMAX Forum, December, 2005 [7] Jenhui Chen, Chih-Chieh Wang, Frank Chee-Da Tsai, Chiang-Wei Chang, Syao-Syuan Liu, Jhenjhong Guo, Wei-Jen Lien, Jui-Hsiang Sum, Chih-Hsin Hung, "The design and implementation of WiMAX module for ns-2 simulator", WNS2 '06: Proceeding from the 2006 workshop on ns-2: the IP network simulator, October 2006 [8] WiMAX for NS-2 http://ndsl.csie.cgu.edu.tw/wimax_ns2.php [9] "MPEG-4 and H.263 Video Traces for Network Performance Evaluation (Master's thesis) Athamneh K. http://trace.eas.asu.edu/TRACE/pics/FrameTrace/h263/index3bc2.html [10] Analysis of Quality of Service in WiMAX networks (Masters thesis) Talwalkar R. [1]

as the number of nodes increase. UGS has higher delay as compared with BE and rtPS flows, although, the delay variation is less for UGS. This is because of UGS offers fixed grants on a periodic basis. There is no bandwidth request mechanism in BE traffic. Data is sent whenever resources are available and not required by any other scheduling-service classes. As the number of nodes increase the average delay increases rapidly for BE service flow as compared to rtPS service flow. In conclusion, rtPS service flow appears to be most optimized for streaming video traffic. UGS service flow appears to perform better especially in terms of packet loss and average jitter. However, UGS service flow has the bandwidth already allocated for the SS to transmit data on a periodic basis, even when there is no data being sent. Hence the network resources are not utilized effectively when UGS service flow is used for streaming video traffic. rtPS service flow performs better than BE service flow in terms of average jitter

IV. CONCLUSION In the paper, the general concepts of Quality of service (QoS) in wireless networks were studied. The IEEE 802.16/WiMAX network architecture was presented and the MAC layer features that enable end-to-end QoS mechanism in the network were discussed. Various service flows that are supported in WiMAX were discussed in details. VOIP traffic and video streaming traffic was analyzed using a simulation based on network simulator, ns-2. The effect of different service flows on QoS parameters like throughput, packet loss, average jitter and average delay was studied. In general, it was observed that the UGS service flow has the least overhead in terms of bandwidth request and it is the highest in rtPS service flow. It can be concluded from the results that the VOIP traffic can be best served with UGS service flow. The UGS service flow is indeed designed for constant bit rate traffic. Periodic bandwidth is already