PolyMAX, a Mobile WiMAX module for the ns-2 simulator with QoS and AMC support

Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Contents lists available at ScienceDirect

Simulation Modelling Practice and Theory journal homepage: www.elsevier.com/locate/simpat

PolyMAX, a Mobile WiMAX module for the ns-2 simulator with QoS and AMC support Sami Ben-Guedria ⇑, Brunilde Sansò, Jean-François Frigon École Polytechnique de Montréal, 2900 boulevard Édouard-Montpetit, Montréal, Canada

a r t i c l e

i n f o

Article history: Received 1 November 2010 Received in revised form 26 April 2011 Accepted 8 June 2011 Available online 12 July 2011 Keywords: ns-2 Simulation tool Mobile WiMAX QoS classes AMC Service flow Scheduler

a b s t r a c t In this paper, we present the PolyMAX module which enhances network simulator 2 (ns-2), the most popular network simulator used in academia, to provide one of the most complete simulation tools to evaluate the performance of Mobile WiMAX networks. PolyMAX is based on the National Institute of Standards and Technology (NIST) module and our specific contributions consist on the design and implementation of the Quality of Service (QoS) classes and QoS management messages, the uplink access grant-request mechanisms, Adaptive Modulation and Coding, and a scheduler handling all five WiMAX QoS classes. We also present validation results for the different components of our module and typical WiMAX simulation scenarios illustrating its flexibility and some of its features. The PolyMAX module represents an important tool enabling researchers to easily implement their Mobile WiMAX scheduling and Adaptive Modulation and Coding (AMC) algorithms and accurately evaluate their performance for realistic scenarios. Ó 2011 Elsevier B.V. All rights reserved.

1. Introduction The Worldwide Interoperability for Microwave Access (WiMAX) wireless technology based on the IEEE 802.16 standards family [1–3] is designed with the primary objective of providing broadband wireless access with Quality-of-Service (QoS) provisioning. Fixed WiMAX based on the IEEE 802.16-2004 standard [1,3] is an attractive alternative to wired broadband technologies due to its fast and low cost deployment. Operators can also use fixed WiMAX in the last mile to provide telephone service with high data rate capabilities. The Mobile WiMAX extension based on the IEEE 802.16e standard [2,3] aims to maintain high-speed connectivity with mobile Subscriber Stations. It offers a global wireless technology that includes residential phone, high data rate Internet connection, television and mobile services, and thus represents an excellent solution for new coming telecommunications operators. Although the standard provides several tools for supporting QoS and mobility, such as different QoS classes and Modulation and Coding Schemes, the scheduling and Adaptive Modulation and Coding (AMC) algorithms required to provide better QoS to mobile users are not specified [4–7]. Fundamental research on Mobile WiMAX, to support a wide array of fixed and mobile applications with various QoS requirements, is therefore crucial to ensure its successful forthcoming deployment. Algorithms based on mathematical models [8–11] provide good insight on the best directions to follow but, given the complexity of the standard, do not necessarily reveal the expected performance in a real Mobile WiMAX network. Indeed, simulation models can describe the network with much more details than mathematical models. On the other hand, using live network deployment to study algorithms is costly and the scenarios that can be studied are limited. Simulation tools thus offer the best compromise to study the effect of new algorithms and protocols with a high degree of realism at a low cost. ⇑ Corresponding author. E-mail addresses: [email protected] (S. Ben-Guedria), [email protected] (B. Sansò), [email protected] (J.-F. Frigon). 1569-190X/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.simpat.2011.06.003

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2077

Acronyms AMC ARQ BE BS CI CID DSA DSC DSD ertPS FDD FTP HTTP LDPC MCS MIMO MPEG mSIR nrtPS ns-2 OFDM OFDMA PMP QoS RR rtPS SF SFiD SNR SS TCL TDD UGS VoIP WiMAX WRR

Adaptive Modulation and Coding automatic repeat request best effort base station confidence interval Connection IDentifier Dynamic Service Addition Dynamic Service Change Dynamic Service Deletion extended real time Polling Service Frequency Division Duplexing File Transfer Protocol HyperText Transfer Protocol Low Density Parity Check Modulation and Coding Scheme Multiple Input Multiple Output Moving Pictures Experts Group maximum Signal to Interference Ratio non real time Polling Service network simulator 2 Orthogonal Frequency Division Multiplexing Orthogonal Frequency Division Multiple Access Point to Multipoint Quality of Service Round Robin real time Polling Service ServiceFlow Service Flow iDentifier Signal to Noise Ratio Subscriber Station Tool Command Language Time Division Duplexing Unsolicited Grant Service Voice over IP Worldwide Interoperability for Microwave Access Weighted Round Robin

The most popular network simulation tool used in academia is probably network simulator 2 (ns-2) [12] that provides substantial support for simulating widespread network protocols for wired and wireless environments. It is particularly popular in the research community due to its open source model which enables unlimited extensibility. In its native implementation, ns-2 does not support the WiMAX technology; however, several extension modules have been proposed for WiMAX. In the following, we survey some of the most interesting WiMAX modules that have been reported in the literature. The LWX module [13] uses the wireless channel of ns-2 and provides some 802.16 MAC functionalities with a basic QoS support. This module is not compatible with the WiMAX mobility specifications and the QoS mechanisms used are not compliant with the 802.16 standard. The Computer Networking Group (CNG) module [14] is dedicated to the mesh topology. It uses the ns-2 wireless channel and does not support QoS and AMC. The National Institute of Standards and Technology (NIST) module [15] is fully compliant with Mobile WiMAX. It provides a realistic WiMAX physical layer with configurable parameters and implements several features such as network entry, handovers and fragmentation. However, service flows and QoS scheduling are not implemented. The module presented in [16] does not implement a WiMAX compatible physical layer (OFDM or OFDMA). The PHY layer is based on the module [17] for simulating the Data Over Cable Service Interface Specification (DOCSIS) [18]. The AMC mechanism is not supported by this module. The MAC layer of [16] implements the five WiMAX QoS classes which are based on the finite state machine proposed by Shrivastav [19] for the DOCSIS project. The module presented in [20] is based on the NIST module [15]. It adds the support of OFDMA but does not implement any of WiMAX QoS classes. The module presented in [21] is also based on the NIST module. This module supports only OFDMA. For the physical layer, it uses a Cost 231 bulk loss component combined with Clarke-Gans implementation of Rayleigh Fading channel. In addition, the QoS support is in progress for this module. These different modules were developed to answer specific research goals and therefore do not possess all the required functionalities to conduct extensive studies for WiMAX. More precisely, the following minimal functionalities are required:

2078

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

compliant with the IEEE 802.16e standard, Orthogonal Frequency Division Multiplexing (OFDM), configurable modulation in the physical layer, and realistic QoS functionalities with a fully configurable parameters. To answer such needs we have implemented the PolyMAX ns-2 module based on the NIST WiMAX module [15]. It thus inherits from this module a realistic WiMAX physical layer and basic MAC functionalities which we enhanced in our module. Our major contributions consist in the addition of a complete QoS support and AMC ability to the NIST module. We implemented new features such as the management of service flows and QoS parameters, the exchange of dynamic service messages needed by the Subscriber Station and the base station to negotiate service flows, and the uplink access grant-request mechanisms for different QoS classes consisting of the unicast polling (unicast request opportunity), the unicast bandwidth request and the contention request opportunities messages. Moreover, we added the ability of dynamically and independently changing, for each unidirectional link, the Modulation and Coding Scheme (MCS) as a function of the instantaneous Signal to Noise Ratio (SNR). The PolyMAX ns-2 module therefore represents an important state-of-the-art tool which enables researchers to easily implement and evaluate the performance of their Mobile WiMAX scheduling and AMC algorithms. The major objective of this paper is to present the design and the different features of the PolyMAX ns-2 module. The paper also proposes a scheduler that takes into account the five WiMAX QoS classes (UGS, ertPS, rtPS, nrtPS and BE). The scheduler supports several disciplines such as Round Robin (RR), Weighted Round Robin (WRR) and maximum Signal to Interference Ratio (mSIR) algorithm. Moreover, it wholly supports all WiMAX QoS parameters in accordance with the 802.16e specifications. The scheduler is evaluated using the PolyMAX module and simulation results, illustrating its performance for different scenarios, are presented. The remainder of this paper is organized as follows. Section 2 presents an overview of the IEEE 802.16 standard making an emphasis on its QoS and AMC features. Section 3 describes the PolyMAX ns-2 module and the proposed scheduler. Validation results of the PolyMAX module are presented in Section 4. Section 5 presents simulation scenarios illustrating the PolyMAX module usage for research purposes to evaluate the performance of Mobile WiMAX networks. Finally, Section 6 concludes the work and presents future research avenues. 2. The IEEE 802.16 standard The 802.16 standard supports two topologies: the Point to Multipoint (PMP) architecture where transmissions are only possible between the Subscriber Station (SS) and the base station (BS), and an optional mesh topology where communications are also possible between SSs. In this paper, we focus on the PMP topology. The 802.16 [1–3] physical layer uses a frame based approach. Each frame is divided into a downlink subframe and an uplink subframe. The downlink subframe is used by the BS to send information to the connected SS. On the other hand, the uplink subframe is shared by all SS’s to send their information to the BS. The frame contents are indicated by the BS to the SSs in two messages called DL-MAP and UL-MAP. Frame duplexing is provided by Time Division Duplexing (TDD) or Frequency Division Duplexing (FDD). The 802.16 MAC layer is a connection oriented protocol. All traffic (Data and control) passing through the MAC layer is mapped into connections identified by a unique 16 bits Connection IDentifier (CID). Each connection is associated with a unidirectional service flow, which is characterized by a unique Service Flow iDentifier (SFiD), a service class name (UGS, ertPS, rtPS, nrtPS, BE) and its associated QoS parameters. Depending on the QoS class and parameters, the subscriber station can send a bandwidth request to the base station. If the request is accepted by the base station, the Subscriber Station will find the transmission parameters details in the UL-MAP at the beginning of the downlink subframe. 2.1. WiMAX QoS classes The WiMAX MAC layer supports five QoS classes. In the case of IEEE 802.16-2004, four classes were defined: the Unsolicited Grant Service (UGS), the real time Polling Service (rtPS), the non real time Polling Service (nrtPS), and the Best Effort (BE). The IEEE 802.16e amendment added the extended real time Polling Service (ertPS) as a fifth QoS class. 2.1.1. The UGS class The UGS class is designed to support real-time flow using fixed-size packets and constant bit rate. This class is used, for example, for the T1/E1 signal transmission or Voice over IP (VoIP) without silence suppression. Fig. 1 illustrates the UGS scheduling mechanism. In this figure as well as in Figs. 2–4 the arrows represents control messages between the Subscriber Station (SS) and the base station (BS). The upwards arrows are messages from the SS to the BS and the downward ones are from the BS to the SS. The numbered boxes are the data packets sent by the SS. The size of these boxes reflects the amount of data sent. The intervals shows the time period between two successive packet transmission. In case of UGS class, the BS provides, at periodic intervals, permission to transmit based on the maximum sustained traffic rate of the service flow. 2.1.2. The rtPS class The rtPS class supports real time data stream with variable-size packet and periodic intervals. For example, compressed audio/video transmission like Moving Pictures Experts Group (MPEG) movies [22] would use this class of service. Fig. 2

2079

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Transmitted packets

Permission to transmit

1

2

3

4 time

interval 1

interval 2

interval 3

Fig. 1. UGS scheduling service: Uplink bandwidth allocation and request mechanisms.

Unicast polling

Transmitted packets

Unicast bandwidth request Permission to transmit

1

3

2

4 time

interval 1

interval 2

interval 3

Fig. 2. rtPS scheduling service: Uplink bandwidth allocation and request mechanisms.

Bandwidth change request Transmitted packets Permission to transmit

1

2

3

4 time

interval 1

interval 2

interval 3

Fig. 3. ertPS scheduling service: Uplink bandwidth allocation and request mechanisms.

Unicast polling

Unicast bandwidth request

Transmitted packets

Permission to transmit Contention bandwidth request

1

2 time

interval 1

interval 2

interval 3

Fig. 4. nrtPS scheduling service: Uplink bandwidth allocation and request mechanisms.

shows how the BS sends periodically unicast request opportunities to allow the station to specify the desired bandwidth through a Unicast bandwidth request.

2080

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2.1.3. The ertPS class The ertPS class is designed to be a compromise between the UGS and the rtPS classes. This class offers an unsolicited unicast grant like UGS class. Thus, latency is minimum because bandwidth requests are not used. However, whereas UGS packet size is fixed, the ertPS packet size can be modified like in rtPS connections. This would be the case of VoIP with silence suppression. Fig. 3 shows the bandwidth allocated change request sent by the SS. After this request, the BS will allocate less bandwidth to the SS in the Uplink subframe.

2.1.4. The nrtPS class The nrtPS class is designed to support delay and jitter tolerant data streams. The packet size is variable, and the time intervals are not necessarily periodic. A minimum reserved traffic rate is assigned to offer a minimum guarantee to nrtPS connections. The nrtPS connections can use contention bandwidth request as well as minimum rate unicast request opportunities to transmit their bandwidth requirements. File Transfer Protocol (FTP) or HyperText Transfer Protocol (HTTP) are examples of traffic assigned to the nrtPS class. Fig. 4 shows that the first packet is sent after two contention based requests. The second packet is sent using a unicast polling opportunity.

2.1.5. The BE class The BE class supports data streams with no QoS guarantees. These connections must use, in general, contention based bandwidth request or unicast request opportunities when the BS offers it. The BS scheduler does not have any obligation towards BE connections.

2.2. Handling service flows Before beginning any transmission, the SS needs a new service flow for each data connection. In the 802.16 standard, only the BS can create, modify or delete a service flow. Service flows are handled using three groups of dynamic service management messages. First, the creation of a new service flow may be initiated by either the BS or the SS and is handled using the following three Dynamic Service Addition (DSA) management messages: the Dynamic Service Addition Request (DSA-REQ) message, the Dynamic Service Addition Response (DSA-RSP) message, and the Dynamic Service Addition Acknowledgment (DSA-ACK) message. In addition to the messages defined for creating service flows, the standard defines three Dynamic Service Change (DSC) management messages allowing the SS and the BS to change the service flow parameters: the Dynamic Service Change Request (DSC-REQ) message, the Dynamic Service Change Response (DSC-RSP) message, and the Dynamic Service Change Acknowledgment (DSC-ACK) message. Finally, an existing service flow can be deleted using two Dynamic Service Deletion (DSD) management messages: the Dynamic Service Deletion Request (DSD-REQ) message and the Dynamic Service Deletion Response (DSD-RSP) message.

2.3. Modulation and Coding Schemes The Mobile WiMAX physical layer uses OFDM modulation and supports various mandatory and optional Modulation and Coding Schemes, such as BPSK, QPSK, 16 QAM and 64 QAM modulation, convolutional, Turbo and low-density parity check (LDPC) codes, and a variety of coding rates through puncturing schemes. Based on the measured channel quality and target QoS, the scheduler can assign on a frame-by-frame basis the most appropriate Modulation and Coding Scheme for each user. This enables a real-time tradeoff between throughput and reliability for each connection.

3. The PolyMAX module The PolyMAX module was developed for the release 2.34 of the ns-2 simulator [12] and is based on the NIST source code [15]. It is designed for the IEEE 802.16-2004 standard and its mobility extension IEEE 802.16e. The implementation was carried out in C++. Many features are already available in the NIST module such as the OFDM physical layer, TDD, network entry management messages, IEEE 802.16e extensions to support scanning and handovers, fragmentation and reassembly of frames. On the other hand, important features like OFDMA, periodic ranging, power adjustments, packing, Adaptive Modulation and Coding, and, in particular, service flow management and QoS scheduling were not implemented. Our contribution consists on the design and the implementation of new QoS classes and the modification of the existent source code to support the newly added features. We added the integrality of the QoS parameters as defined in the IEEE 802.16e standard. We also designed and implemented two schedulers, one for the BS and the other for the SS. These schedulers fully support the five WiMAX QoS classes and AMC. The bandwidth allocation mechanisms for some of these classes need new additional messages; we thus added the unicast and contention request opportunities mechanisms. All modifications are backward compatible such that simulation scripts written for the NIST module are functional with the PolyMAX module.

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2081

Fig. 5. PolyMAX MAC layer class diagram.

3.1. The MAC layer classes Fig. 5 presents the main classes of the MAC layer module. Most of these classes have been inherited from the NIST module but were modified or completely redesigned to support new features. In addition, the interface of these classes has been enhanced with four new functions allowing ns-2 users to handle service flows. The Mac802_16 is an abstract class. It contains the common elements of the BS and the SS. It is the main interface with other layers to send and receive packets. Since the BS and the SS have different state machines, two subclasses (Mac802_16BS and Mac802_16SS) are defined. A Subscriber Station is registered to a base station during the network entry procedure which has been modified to consider sending DSA messages after the registration. The class peerNode contains information about each BS/SS peer such as: connection, modulation used and status (disconnected, connected, waiting for synchronization, ranging, waiting for ranging response, register, scanning, etc). Additional information fields have been implemented to support the new timers used by the schedulers and the SNR thresholds required by the AMC algorithm. Each node (BS or SS) has an instance of the ConnectionManager class to manage all its connections. The ConnectionManager class contains the list of incoming and outgoing connections. In the previous model, the class ConnectionManager supported only one data connection per peer. This class was thus extended to handle multiple data connections. The Connection class, which contains all information about a specific unidirectional connection, has also been modified. Each connection can now be associated with a service flow instance. The interface of the Connection class has also been upgraded to allow access to the ServiceFlow class members through the ConnectionManager and ServiceFlowHandler classes. The following classes handling the scheduling, service flows and QoS were completely redesigned. The ServiceFlowHandler class responsible for handling the list of service flows, the ServiceFlow class emulating a service flow in the MAC layer, and the ServiceFlowQoS containing the service flow QoS parameters are discussed in details in Section 3.2. The SSscheduler class and the BSscheduler class perform the Subscriber Station and the base station scheduling algorithms, respectively. They are discussed in details in Sections 3.3 and 3.4. 3.2. QoS classes The NIST module does not support QoS, but it provides a simple design of three QoS classes for future extensions: the ServiceFlowHandler, ServiceFlow and ServiceFlowQoS classes. The classes names were preserved, but they were redesigned and reimplemented. 3.2.1. QoS parameters The QoS parameters are managed by the ServiceFlowQoS class. According to the IEEE 802.16e standard, we added the following parameters to this class:  The traffic priority: The value of this parameter indicates the priority assigned to a service flow.  The maximum sustained traffic rate (bits/s): It defines the peak data rate of a service flow.

2082

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

 The minimum reserved traffic rate (bits/s): It specifies the minimum rate reserved for a service flow.  The tolerated jitter (ms): It defines the maximum delay variation (jitter) for the connection.  The maximum latency (ms): The value of this parameter specifies the maximum latency between the reception and the forwarding of a packet on the RF air interface.  The Uplink grant scheduling Type: The value of this parameter specifies the uplink grant scheduling service type (UGS = 6, rtPS = 4, nrtPS = 3, ertPS = 5, BE = 2 (default)).  The Unsolicited Grant Interval (ms): The value of this parameter indicates the interval between successive data grant opportunities for a service flow.  The Unsolicited polling interval (ms): The value of this parameter specifies the maximal interval between successive polling grants opportunities for a service flow. 3.2.2. Dynamic service The addition, modification or deletion of a service flow need dynamic service messages (DSA, DSC and DCD) exchanges between the SS and the BS. The NIST module implements DSA messages, but it does not take into account the QoS parameters or service flow specifications. On the other hand, the Dynamic Service Change (DSC) and Dynamic Service Deletion (DSD) messages are not implemented. Our contribution consisted in the modification of the DSA management messages and the implementation of the DSC and DSD messages. All those modifications have been performed in the ServiceFlowHandler class. The QoS parameters of the requested service flow have been added to the DSA-REQ message. The packet format and size have been then updated. Fig. 6 presents the procedure for creating a new service flow. The Subscriber Station sends a DSAREQ message for each new service flow. The DSA-REQ contains the set of service flow QoS parameters. When receiving the DSA-REQ message, the base station checks the possibility to meet the request. In the affirmative case, a new Service Flow iDentifier (SFid) is created with its corresponding CID. Receiving the DSA-RSP, the SS assigns the SFid and the CID to the corresponding service flow and connection. A DSA-ACK is then sent to confirm the reception of the DSA-RSP message. From this moment, the subscriber station can send and receive data. The Dynamic Service Change (DSC) messages are used to modify service flow parameters. Fig. 7 presents the implemented service flow modification procedure. When a service flow requires a modification, the Subscriber Station sends a DSC-REQ containing the SFid of the service flow and the requested QoS parameters. If the DSC-REQ is validated by the base station, the service flow parameters will be modified. The DSC-RSP received by the SS will confirm or not the modification. If the request is accepted, the service flow parameters can be updated, and a confirmation DSC-ACK is sent. When the BS receives the DSC-ACK, the service flow new status is activated, and the scheduler database is updated. The Dynamic Service Deletion (DSD) messages are used to delete a service flow. In Fig. 8 we present the implemented service flow deletion procedure. An SS wishing to delete a service flow sends a DSD-REQ message to the BS. The BS verifies the service flow owner. If the identity matches, the SF is removed, and a DSD-RSP message is sent to the SS. 3.3. Uplink access grant-request mechanism The uplink access grant-request mechanism is required to handle rtPS, nrtPS and BE connections. This procedure was not implemented in the NIST module and modifications to the Mac802_16BS, Mac802_16SS, SSscheduler and BSscheduler classes were done to support it.

SS

BS

Set the requested QoS parameters DSA - Req Validate the request Creat a new CID and SFiD DSA - Rsp Activate the Service Flow or send another request DSA - Ack Save the new Service Flow parameters Begin the transmission

t

t

Fig. 6. Create a new service flow.

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

SS

2083

BS

Set the requested QoS parameters Set the SFiD of the Service Flow

DSC - Req Validate the request Modify the Service Flow Increase/decrease allocated bandwidth DSC - Rsp

Update the Service Flow parameters DSC - Ack The new SF status is activated Scheduler will take in account the new parameters for the next frames t

t

Fig. 7. Modification of a service flow parameters.

SS

BS

Delete the Service Flow in the SS local database DSC - Req Verify if the SS is the Service Flow owner Delete Service Flow DSC - Rsp

t

t

Fig. 8. Deletion of a service flow.

3.3.1. Unicast request opportunities The unicast request opportunities are used by the BS to allow subscriber station using rtPS, nrtPS and BE connections to specify the desired bandwidth for each uplink transmission. For UGS and ertPS connections, unicast request opportunities (also called unicast polling) are not needed. For UGS connections, the traffic rate is constant during all the connection time. For the ertPS connections, the traffic rate can be changed using DSC management message. Once modified, the traffic rate stays unchanged until the next DSC message. In the NIST module, the unicast polling is not supported and bandwidth allocation is only performed using contention request opportunities. We implemented a unicast polling opportunities mechanism working as follows. First, when a new rtPS or nrtPS service flow is created, a polling timer is assigned to it in the BS database (PeerNode class). This timer is first initiated with the unsolicited polling interval value from the service flow parameters and is then decremented in every frame by the frame duration. When the BS scheduler begins serving rtPS connections, it checks the polling timers of each connection. When a timeout occurs, the BS scheduler sends a unicast request to the correspondent connection and update the timer value with its initial value. For the nrtPS connections, the procedure is similar, but the timer duration is set by the BS scheduler according to the network policy and the polling only occurs if the current connection transmission rate is below the granted minimum rate. The standard just states that the BS polls nrtPS connections on the order of 1 s or less. For BE connections, there are no guarantees accorded regarding periodicity, so we do not affect a timer to them. Thus, the BS scheduler sends a unicast request opportunity according to the network policy used for BE connections. 3.3.2. Unicast bandwidth request The unicast bandwidth request is not implemented in the NIST module. Indeed, only the BE class is implemented in the existing code. There is thus no need to use unicast bandwidth requests, and contention request. We implemented a unicast bandwidth request mechanism that works as follows. When a Subscriber Station receives a unicast request opportunity for one of its rtPS or nrtPS connections, the SS sends a unicast bandwidth request. This request contains the uplink data length of the connection, according to the service flow parameters. For a BE connection, the unicast bandwidth request contains the length of its uplink data connection queue. Once the unicast bandwidth request is sent and served by the scheduler, the BS

2084

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

allocates an uplink burst in the next frame, and a DL-MAP-IE (Down Link MAP Information Elements) [1–3] is added. The DLMAP-IE contains the following information:    

CID: indicates the connection identifier that the connection has to use. UIUC: defines the burst type associated with that burst time interval. Start: indicates the start time, in units of OFDM symbols, relative to the start of the first OFDM symbol. Duration: indicates the duration, in units of OFDM symbols, of the allocation.

3.3.3. Contention bandwidth request The contention request is sent using the contention slot for bandwidth request at the beginning of the uplink subframe [1–3]. The model supports a truncated binary exponential backoff [23]. The contention period as well as the initial and maximum backoff window size are set using the TCL script. The NIST module implements the contention bandwidth request but we modified the existent code by allowing just nrtPS, BE and management connections (Basic, Primary and Secondary) to use the contention bandwidth request. The function sending contention bandwidth request has also been generalized to identify the connection type. 3.4. Scheduling The QoS flows are not implemented in the NIST module and the existing scheduler algorithm is thus based on station scheduling rather than connection scheduling. Contention bandwidth requests are sent by the Subscriber Station in order to have the permission to emit. Once this permission is delivered, a station can send data from its BE connection as well as management connections (Basic, Primary and Secondary). We redesign the scheduler to differentiate between management and data connections, and support the five WiMAX QoS classes as well as AMC. Note that this scheduler, while complete, is basic since our goal in this paper is only to present the PolyMAX module. However, by taking advantage of the module flexibility and modularity, researcher can easily replace this scheduler by more advanced algorithms, such as opportunistic scheduling, and study them in a realistic WiMAX environment. Fig. 9 presents a general overview of the proposed scheduler. The scheduler begins by creating a list of active connections. These connections are sorted according to their type (data or management) and then the data connections are sorted according to their QoS class (UGS, rtPS, nrtPS, ertPS, BE). Afterward, the scheduler serves connections according to their class priority and QoS parameters. 3.4.1. The UGS scheduler Fig. 10 presents the flowchart diagram of the designed UGS class scheduler. First, the scheduler scans the list of UGS connections registered in the BS database. This list is sorted according to the connection traffic priority parameter. The scheduler can serve the connections according to a weighted Round Robin scheduling discipline, a mSIR discipline using the connection link SNR, or a simple Round Robin scheduling discipline based on the registration order of the UGS connections (the same

Start a new frame

Update variables Browse and sort the connections list

Are there connections to serve ?

YES

Schedule management connections

Schedule UGS connections NO

Schedule ertPS connections Schedule rtPS connections Schedule nrtPS connections Schedule BE connections

Fig. 9. The new scheduler model.

End

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2085

START

Scan the UGS list and choose the next connection NO

Has the connection timer expired ? NO YES Calculate the transmission time and the number of OFDM symbols

YES

Are there enough symbols in the frame ? YES Add a new burst and update the UL_MAP

Update the remaining symbols in the frame

Are there enough symbols in the frame ?

YES

Are there other connections to serve ?

NO

NO END

Fig. 10. UGS scheduler processing.

connections scheduling disciplines are available for the five schedulers). Once a connection is chosen, the scheduler checks the connection timer. As we saw in Section 2.1.1, the BS grants bandwidth periodically to the UGS connections. This period is set by the user according to the traffic specifications. If the timer is not yet expired, the scheduler chooses the next connection to serve. If the timer is done, the scheduler has to grant bandwidth for the given connection in the current frame. Then, the scheduler computes the transmission time and the number of OFDM symbols to be allocated, based on the current MCS and connection parameters. If there are not enough symbols in the frame to serve the current connection, the scheduler does not allocate bandwidth and go on with the next connection. In the opposite case, the scheduler adds a new burst in the frame and updates the UL_MAP. As long as the frame still has enough symbols, the scheduler continues serving the remaining UGS connections. 3.4.2. The ertPS scheduler The ertPS class is very similar to the UGS class. The only difference is that the packet size of an ertPS connection can be changed during a communication session, exactly like with rtPS connections. This is used, for example, with VoIP with silence suppression to save bandwidth. To allow ertPS to be more efficient than rtPS, the modification request is sent once and stays valid until the next possible request. Between two traffic rate modifications, the ertPS connection is handled exactly like an UGS connection. The core design of our ertPS scheduler is thus the same than the UGS one, with the peculiarity that the traffic rate modifications is handled by the service flow class. Once a modification is accepted, the current traffic rate

2086

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

parameter of the connection is updated. When the ertPS scheduler scans the list of ertPS connections, it obtains the newest value of traffic rate and allocates the desired bandwidth to the connection. To summarize, the traffic modification phase of an ertPS connection is handled by the service flow class, and the transmission phase by an UGS like scheduler. 3.4.3. The rtPS scheduler Fig. 11 presents the flowchart diagram of the designed rtPS class scheduler. First, the scheduler scans the list of rtPS connections and chooses the next connection to serve according to the used scheduling discipline (RR, WRR or mSIR). If the timer has expired, the scheduler checks if the connection has already sent a bandwidth request. If the connection did not have a bandwidth request, a unicast request is sent in the current frame. The value of the timer is not changed and stays resetted to indicate that the connection has to be served in the next frame. If the connection has a bandwidth request, the rtPS scheduler checks the validity of the request according to the QoS parameters of the connection. Then, it computes the transmission time and the number of OFDM symbols to allocate, based on the current MCS. If the frame has enough symbols, the scheduler adds a new burst and updates the UL-MAP. Finally, the scheduler initializes the connection timer to respect the periodicity of the unicast polling request. As long as the frame still has enough symbols, the scheduler continues serving the remaining rtPS connections. 3.4.4. The nrtPS scheduler Fig. 12 presents the flowchart diagram of the designed nrtPS class scheduler. First, the scheduler scans the nrtPS list and chooses the next connection to serve according to the used scheduling discipline (RR, WRR or mSIR). If the chosen connection does not have a submitted bandwidth request, the scheduler checks if the timer is done. If it is the case and if the minimum rate requirement has not been reached, a unicast request is sent. The timer is thus used to ensure a minimum traffic rate to nrtPS connections by contrast with the rtPS timer which ensures periodicity. In case the connection has submitted a contention bandwidth request, the scheduler checks the conformity of this request with the connection QoS parameters. Then, according to the MCS, it computes the required time duration and the number of OFDM symbols. If there are enough symbols, it creates a new burst for the connection, updates the frame length and initializes the timer. The nrtPS scheduler continues working until all nrtPS connections have been checked or there are not enough symbols in the current frame. 3.4.5. The BE scheduler Fig. 13 presents the flowchart diagram of the designed BE class scheduler. First, the scheduler scans the list of BE and chooses the next connection to serve according to the used scheduling discipline (RR, WRR or mSIR). The scheduler checks if the connection had submitted a bandwidth request. If it is not the case, the BE scheduler chooses the next connection to serve. If the connection has a bandwidth request, the scheduler computes, based on the MCS, the transmission duration and the number of OFDM symbols. If the remaining number of OFDM symbols is insufficient, the scheduler allocates the rest of symbols to the current connection. In this case, the scheduler goes directly to the end state because all the frame resources have been allocated. In the opposite case, a new burst is created. The UL-MAP and the remaining symbols variable are then updated. As long as the frame still has unallocated symbols, the scheduler continues serving the remaining BE connections. 3.5. Adaptive Modulation and Coding The NIST physical layer offers the possibility of using seven different MCSs. In the original implementation, the MCS is set by the ns-2 user via the TCL script and is used as the default transmission MCS. Thus, all Subscriber Stations use the same MCS throughout the entire simulation. To allow dynamic change of the MCS during the simulation, an AMC [24] is implemented based on SNR thresholds. A new TCL function (set-SNR) is designed to allow the setting of the instantaneous SNR of each Subscriber Station. This value is periodically updated and stored in a newly defined database in the base station class Mac802_16BS. We also modified the five schedulers to handle Adaptive Modulation and Coding. The suitable MSC is chosen based on the threshold value given as reference in the 802.16e amendment [2,3] in order to maintain the maximum throughput while respecting an acceptable frame error rate. These thresholds are obtained in an AWGN (Additive White Gaussian Noise) environment with Reed-Solomon convolutional coding. This new feature allows an efficient emulation of SS mobility for Mobile WiMAX. The SNR scenarios may be generated randomly with an internal generator, or with an external tool generating SNR values according to a specific physical environment and subscriber mobility scenario. By decoupling the physical channel modeling from ns-2 through the TCL interface, we avoid time consuming computations in ns-2 and use more appropriate tools such as Matlab to simulate the physical layer performance. Table 1 presents the supported MCSs along the SNR threshold value and the measured downlink throughput using the PolyMAX module with 10 MHz bandwidth, 5 ms frame duration and a downlink subframe ratio of 0.85. 4. Validation of the PolyMAX module The simulations in this section were performed to check the validity and compliance of the PolyMAX module with the IEEE 802.16e standard. The simulation results are extracted from the ns-2 trace file and/or directly from the scheduler via

2087

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

START

Scan the rtPS list and choose the next connection NO

Did the connection timer expire ?

YES YES

NO Does the connection have a bandwidth request ?

YES

Check the request validity

NO

Send a Unicast Request

Calculate the transmission time and the number of OFDM symbols Are there other connections to serve ?

YES Are there enough symbols in the frame ?

YES Add a new burst and update the UL_MAP

Update the remaining symbols in the frame NO Initialize the connection timer

Are there enough symbols in the frame ?

NO

YES

Are there other connection to serve ?

NO

END

Fig. 11. rtPS scheduler processing.

a log file created for this purpose. The PMP topology is used throughout all simulations combined with TDD duplexing mode. The BS was located at the center of a 1000 m  1000 m area. We always considered scenarios with one base station and several Subscriber Stations distributed around the BS. Unless it is otherwise indicated, the SNR was set to a large value ensuring that 64-QAM modulation is used with 3/4 coding rate. The frame duration was 5 ms, the channel bandwidth was 20 MHz and we assumed a 2:1 uplink to downlink split ratio. To facilitate the results analysis, the connections within the same QoS class had the same priority.

2088

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

START

Scan the nrtPS list and choose the next connection YES

NO

Did the connection have a bandwidth request ? NO

NO YES

YES

Did the connection timer expire ?

Check the request validity

Calculate the transmission time and the number of OFDM symbols

YES

YES

YES

Does the minimum rate been reached ?

Are there enough symbols in the frame ?

NO YES

Send a Unicast Request

Add a new burst and update the UL_MAP

Initialize the connection timer

Update the remaining symbols in the frame Are there other connections to serve ? Are there enough symbols in the frame ?

NO

NO

YES

Are there other connection to serve ?

NO

END

Fig. 12. nrtPS scheduler processing.

4.1. Validation of the AMC mechanism The AMC mechanism implemented in the PolyMAX module was validated using a scenario with one BS and one SS. The simulation time was 450 s and the SNR was updated each 5 s. The SNR to the SS was generated using a uniform distribution in the range of 0–25 dB. The SS used an uplink CBR traffic through an ertPS connection in the uplink channel and a BE connection in the downlink channel. Fig. 14 shows one realization of the received SNR variation in time and how the BS scheduler adapts the MCS in use as a function of this SNR. The results obtained are in compliance with the IEEE 802.16e assumptions presented in Table 1. The mean throughput obtained with AMC for this scenario was 15.519 Mbps with a confidence interval of 0.198 Mbps. 4.2. Validation of the UGS service flow The UGS service grants the transmission of fixed data packets at constant time intervals Section 2.1.1. To check whether or not a UGS connection receives periodic grants for transmission, we simulated a simple network with one SS and one BS. The SS uses an UGS uplink connection with a constant data rate of 64 Kbps and a periodicity of 10 ms.

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2089

START

Scan the BE list and choose the next connection NO

Did the connection have a bandwidth request ?

YES Calculate the transmission time and the number of OFDM symbols

Are there enough symbols in the frame ?

YES YES

Add a new burst and update the UL_MAP

NO

Add a new burst with remaining symbols in the frame and update the UL_MAP

Update the remaining symbols in the frame

Are there other connections to serve ?

NO

END

Fig. 13. BE scheduler processing.

Table 1 MCS and AMC parameters. Modulation

Coding rate

BPSK

1/2

Receiver SNR(dB) 3.0

Measured throughput (Mbps) 6.198

QPSK

1/2 3/4

6.0 8.5

6.438 9.737

16-QAM

1/2 3/4

11.5 15.0

12.990 19.659

64-QAM

2/3 3/4

19.0 21.0

25.650 28.652

Fig. 15 shows communications between the SS and the BS. First, the SS demands a new UGS connection by sending a Dynamic Service Addition (DSA) message (1) which contains the suitable QoS parameters. If the BS scheduler estimates that it is possible to add a new UGS connection with such parameters, a DSA Response (2) is sent to the SS. The SS validates the operation by sending a DSA acknowledgment. From this moment, the new service flow is activated and the scheduler will allocate

2090

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Fig. 14. AMC validation.

bandwidth resource periodically for this UGS connection. In (4), a permission to transmit is sent to the SS in frame number 6284 which allows the SS to transmit in frame 6285, from the 22th symbol, during 1 symbol, and using the QAM-64 3/4 scheme. In (5), the packet number 26 is transmitted with the corresponding parameters. After exactly 10 ms, in frame 6286 a new permission to transmit is sent to the SS and the same procedure is repeated. This results shows that the designed UGS scheduler is in accordance with the 802.16 standard. 4.3. Validation of the ertPS service flow The ertPS service flow is very similar to the UGS service (constant packet size and periodicity), except to the fact that it can dynamically modify the packet size Section 2.1.3. To validate the smooth running of the ertPS scheduler, we simulated a network with one SS using silence detection and sending at a constant data rate of 64 Kbps during active periods and with a periodicity of 10 ms. Fig. 16 shows communications between the SS and the BS. After the creation of a new ertPS service (1, 2, 3), the SS starts transmitting at the initial rate of 64 Kbps. When a silence period is detected (after 30 ms), the SS sends a bandwidth change request (6). The BS scheduler cease allocating bandwidth until the SS send a request (7) via a management connection message to restore its previous setting. A permission to transmit is then sent to the SS in the next frame. This communication sequence shows the conformity of the designed ertPS service with the standard guidance. 4.4. Validation of the rtPS service flow The rtPS service grants the transmission of variable data packets at constant time intervals Section 2.1.2. To analyze the operation of the rtPS scheduler, a simulation with one SS sending video traffic and using a rtPS service is performed. The video traffic is generated based on a real MPEG-4 traces [25]. Table 2 shows the characteristics of the MPEG-4 traffic used in this simulation. Fig. 17 presents a communication sequence between the SS and the BS. The SS creates a new rtPS service flow (1, 2, 3) according to its traffic parameters. In (4), the BS sends a unicast polling allowing the SS to transmit its unicast bandwidth request (5) in the next frame. The BS scheduler computes the amount of symbols needed and a permission to transmit (6) is sent containing all the transmission parameters. In (7), the SS transmits the amount of data requested previously in (5). Then, a new unicast polling (8) is sent exactly after a period of 30 ms, according to the QoS parameters requested in (1). This communication sequence illustrates the conformity of the designed rtPS service with the standard. 4.5. Validation of the nrtPS service flow The nrtPS service flow is designed to handle applications with delay and jitter tolerance, and a required minimum data rate threshold Section 2.1.4. Basically, the nrtPS connections use contention bandwidth requests to send their traffic requirements. However, if the BS scheduler detects that the minimum rate is not reached, unicast polling opportunities are sent to

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2091

Fig. 15. UGS service validation.

the SS. The simulation scenario used to test the proper functioning of the nrtPS service consists of one BS and 20 SS. Every station had a nrtPS flow and generated a constant traffic rate of 128 kbps. The size of the backoff windows is deliberately chosen small to cause bandwidth request collisions and force the BS to use unicast polling to compensate. Fig. 18 illustrates a communication sequence between one SS and the BS. In (1), a Dynamic Service Addition (DSA-REQ) is sent to the BS. This DSA requests a new nrtPS service with a maximum sustained traffic rate of 1 Mbps and a minimum reserved rate of 64 kbps. The unicast polling interval is set to 1 s according to the standard recommendation. The request (1) is accepted in (2) and a new SFid and CID is assigned to the connection. The SS sends a contention bandwidth request (4) for the 10 packets awaiting in the connection queue. The request is successfully received by the BS and a permission to transmit (5) is sent. In (6), the SS transmit the packets according to the parameters specified in (5). Immediately after this transmission, the SS sends a new contention bandwidth (7) for the new packet number 130 enqueued just after (4). Due to a collision in the contention procedure, the request is lost. Then, the SS continues sending bandwidth requests according to the backoff procedure. We can notice the increasing value of the bandwidth requested because of the uninterrupted arrival of packets in the connection queue. When the polling timer is done, the BS scheduler check the amount of data transmitted by this connection. Since the granted minimum rate (64 kbps) is not reached, a unicast polling (9) is sent to the SS. In (10), a unicast bandwidth request is transmitted for the 12 packets pending in the nrtPS connection queue. The BS verify that the overall size does not exceed the maximum sustained traffic rate and a permission to transmit (11) is sent in the next frame. In (12), the awaiting packets are sent according to the previously sent parameters. This communication example shows the conformity of the designed nrtPS service with the standard guidance.

2092

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Fig. 16. ertPS service validation.

4.6. Validation of the BE service flow The BE service flow is designed for applications with no delay or jitter requirements Section 2.1.5. Unlike nrtPS connections, BE connections only use contention based uplink polling for the bandwidth request. The simulation scenario used to test the BE service operation consists of one BS and 20 SS. Each station has an uplink BE flow and generates a constant traffic rate of 1 Mbps. The backoff windows size is intentionally chosen small to induce bandwidth request collisions. This will allow us to better demonstrate the scheduler work. Fig. 19 presents an example of communication sequence between one SS and the BS. The SS sends a DSA request (1) to demand a BE connection. The request is accepted by the BS, and a DSA response (2) is sent. The SS validates the operation by sending a DSA acknowledgment (3). After the packet number 145 is enqueued, a contention bandwidth request (4) is sent in the next frame. This request is lost due to the backoff procedure. The SS continues sending bandwidth request for 60 ms,

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2093

Table 2 MPEG-4 video traffic characteristics. [25]. Frame statistics Compression ratio (UV:MP4) File size (byte) Video run time ms Number of frames Mean frame size (byte) var frame size (byte) CoV of frame size Min frame size (byte) Max frame size (byte) Mean bit rate (bit/s) Peak bit rate (bit/s) Peak/Mean of bit rate

17.91 6.4e+07 1.2e+06 30335 2.1e+03 2.6e+06 0.75 0 22188 4.2e+05 4.4e+06 10.45

until the request (6) succeed to be properly received by the BS. The BS checks the remaining bandwidth resource available and sends a permission to transmit (7) in the UL-MAP of the frame number 6260. It allows the SS to transmit in the next frame. In (8), the 2 pending packets are transmitted by the SS. This communication sequence verify the conformance of the designed service with the BE standard guidance. 5. Simulations using PolyMAX module This section presents five simulations scenarios using the PolyMAX module. The first was performed to express the endto-end delay in terms of the SS numbers using different QoS classes; the simulation results were compared with theoretical analysis based on [26,27]. The second scenario presents the theoretical and simulated maximum throughput at the MAC layer in terms of the different Modulation and Coding Schemes. The third was conducted to illustrate an example of bandwidth allocation handling the five QoS classes. The fourth scenario was undertaken to show the delay distribution in terms of QoS classes whereas the fifth highlights the impact of the frame duration on the average delay and jitter. The final simulation is conducted to evaluate the module performance. Throughout all simulations, the only BS was located at the center of a 1000 m  1000 m area. Typically, the frame duration was 5 ms except for the fourth scenario. Note that our goal here is not to do a thorough study of WiMAX or the scheduler performance but to illustrate the features and flexibility of the PolyMAX module. 5.1. The average delay in terms of station number In this scenario, a set of simulations was performed with the number of SS increasing from 1 to 35. Three service classes (UGS, rtPS and BE) were tested independently (i.e., in a simulation all SSs have the same service class). Traffic sources with the same characteristics were used to simulate the uplink traffic for the three QoS classes. To simplify the analytical study, Poisson arrival are used. Otherwise, the packet size is constant (1500 Bytes). By using this traffic model, the ertPS and nrtPS class would behave exactly as the UGS and BE classes, respectively. The use of the same traffic model for all classes is particularly pertinent in this step to appreciate the impact of increasing the network load without the traffic variation repercussion on the delay [28]. The periodicity of the unicast polling, for the UGS and rtPS connections, are respectively 5 ms and 20 ms. The channel bandwidth was 20 MHz and the arrival rate is the same for all connections. The delay was computed between the application layer of the SS and a router linked to the BS through a 100 Mbit link with a 1 ms delay. Fig. 20 presents analytical and simulated average delay for uplink connections in terms of the number of SSs for UGS and rtPS classes. The results show as expected that the delay of UGS and rtPS connections is not affected by the increase of the SSs number. Indeed, before registering an UGS or a rtPS connection, the scheduler checks if the QoS parameters requested could be respected. Note that the rtPS delay is longer than for UGS due to the uplink access grant-request mechanism delay. The analytical model, derived from [26], confirms the accuracy of the simulated results. Fig. 21 presents the analytical and simulated average delay for uplink connections in terms of the number of SSs for the BE class. We notice that unlike UGS and rtPS, the delay of BE connections increases with the offered load. This is due to contention based bandwidth request used in WiMAX for BE connections. The BE bandwidth requests are sent using a truncated binary exponential backoff models [23]. The start and stop backoff window size are respectively 2 and 16. The analytical study is based on the model presented on [27]. As we see, the analytical model fits fairly well the simulated results and confirms the accuracy of the presented module (the measured average error was 6%). The difference between analytical and simulated curves, from point 3 to 7, can be explained by the simplifying assumptions made in the analytical model. 5.2. Troughput in terms of bandwidth In this scenario, a set of simulations was performed to evaluate the data throughput performance at the MAC layer. Since the throughput is a constraint for real-time services, the BE class is used for this scenario. The uplink to downlink split ratio

2094

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Fig. 17. rtPS service validation.

was set to 1:2 (i.e 0.66 allocated for the downlink subframe and 0.33 for the uplink subframe). The Transmit/receiver Transition Gap (TTG) and the Receive/transmit Transition GAP (RTG) hold 20 symbols and the cyclic prefix was 1/16. The analytical performance was derived from [29,30]. The uplink and downlink throughput was measured for the following seven Modulation and Coding Schemes: 1. 2. 3. 4. 5. 6.

BPSK-1/2 QPSK-1/2 QPSK-3/4 16QAM-1/2 16QAM-3/4 64QAM-2/3

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2095

Fig. 18. nrtPS service validation.

7. 64QAM-3/4 Fig. 22 presents the analytical and simulated throughput for the uplink channel. A station using an uplink BE connection generates a CBR traffic exceding the capacity of channel. The uplink BE scheduler will allocate all the available uplink bandwidth for this station. The received data is measured at the MAC layer of the BS. Fig. 23, on the other hand, compares the analytical and simulated throughput for the downlink channel. To evaluate the downlink channel, a node connected to the BS generates a CBR traffic exceding the downlink capacity. The received data is measured at the MAC layer of the SS using a BE downlink connection. As for the uplink scenario, the downlink BE scheduler will allocate all the available downlink resource and reveal the maximum data rate. The analytical model fits almost perfectly with the simulated results and confirms the accuracy of the simulated throughput for all Modulation and Coding Schemes (the measured average error was 1%). 5.3. Bandwidth allocation Fig. 24 shows the percentage of bandwidth allocated for each QoS class in terms of time. These values were extracted from the log file generated by the scheduler. The simulation contains 6 UGS connections and 6 ertPS connections using both a CBR

2096

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Fig. 19. BE service validation.

Fig. 20. Average delay versus number of SSs for UGS and rtPS connections.

traffic source at 64 Kbps. We emulated a silence suppression from the moment 21.5 s for the ertPS connections. We also had 3 rtPS connections using MPEG-4 traffic sources. The traffic was generated based on a real MPEG-4 trace file [31]. The mean

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2097

Fig. 21. Average delay versus number of SSs for BE connections.

Fig. 22. Throughput for uplink channel.

Fig. 23. Throughput for downlink channel.

rate of this MPEG-4 source was 0.197 Mbps, and the peak rate was 1.329 Mbps. We also had 5 nrtPS and 10 BE connections using CBR sources at 512 Kbps. The traffic starts and stops moments of the nrtPS and BE connections were randomly chosen

2098

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

to emulate a VBR traffic. The channel bandwidth was 5 MHz. In this example, we showed the cohabitation of the 5 QoS service within the same scenario. In the following simulations, we will get more insight on the performance by measuring the delay experienced by the different service classes. 5.4. The delay distribution in terms of QoS classes In the fourth scenario, there were 3 SSs using UGS connections, 5 SSs using rtPS connections and 9 SSs using BE connections. We have considered voice, video and WEB traffic, which were associated with UGS, rtPS and BE connections, respectively. For UGS connections, an uncoded voice model without silence suppression was used. The traffic rate was 64 Kbps, and the packet size was 80 Bytes. The period between two Unicast Polling was 10 ms. For rtPS connections, the video traffic was generated using a real MPEG-4 trace [31]. The traffic mean rate of this video was 0.197 Mbps, and the peak rate was 1.329 Mbps. The period between two Unicast Polling was 40 ms. For BE connections, the WEB traffic was modeled using an exponential inter arrival distribution with 2 Kbytes packet size. The channel bandwidth used was 10 MHz. Fig. 25 shows the end-to-end delay distribution of the packets in terms of the QoS class. A set of simulations was performed and the packets of each class have been classified according to their delay. 5.4.1. UGS class connections According to the ITU-T recommendations [32], a VoIP call is considered as of excellent quality if the delay does not exceed 150 ms. A VoIP user is in outage if more than 2% of its packets are not delivered successfully within the given delay bound. By considering 100 ms for the wired network, we had a delay bound of 50 ms. Considering this delay bound, the measured success rate is 100%. The mean delay for the UGS packets is 6.1 ms, and the variance is 0.009 ms. More than 90% of the UGS packets experience a delay below 10 ms. 5.4.2. rtPS class connections Based on Ref. [33], the maximum packet delay budget for non-conversational buffered video is 300 ms. We consider that the maximum delay allowed for wireless interface is 200 ms, taking into account 100 ms for the wired network. Under this

Fig. 24. Percentage of bandwidth allocated.

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2099

Fig. 25. Delay distribution.

Fig. 26. Uplink average delay/jitter in terms of frame duration using 60 UGS connection.

condition, the measured success rate is 99.99%. The mean delay is 61.1 ms, and the variance is 0.7 ms. More than 90% of rtPS packets have a delay between 20 and 100 ms. 5.4.3. BE class connections For BE connections, the mean delay is 131.8 ms, and the variance is 6.2 ms. About 90% of the BE packets have a delay between 10 ms and 230 ms.

2100

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

Fig. 27. Execution time in terms of station number.

5.5. Impact of the frame duration on the delay and jitter In the fifth simulation, we consider 60 SSs using the UGS class. A set of simulations was performed with several frame durations. The frame duration values depend on the used physical layer (OFDM or OFDMA). The duration values used in the simulation are consistent with WiMAX OFDM physical layer [1–3] and the periodicity of the UGS connections was fixed at 2 (i.e., one polling every 2 frames). The channel bandwidth used was 20 MHz. Each station has one UGS connection generating a CBR traffic of 64 Kbps. The simulation time was 1800 s. Fig. 26 presents the average delay and jitter in terms of the frame duration. As expected, the delay and the jitter increase on a pro rata basis. The average delay corresponding to a 2.5 ms frame is 4.07 ms with a 95% confidence interval (CI) of 0.057 ms. The measured jitter is 1.71 ms with a CI of 0.037 ms. On the other hand, the mean delay corresponding to a 20 ms frame duration is 36.35 ms with a CI of 5.78 ms. The mean jitter is 18.06 ms with a CI of 5.63 ms. 5.6. PolyMAX performance The final simulation was conducted to evaluate the performance of the ns-2 simulator using the PolyMAX module. The simulation was conducted on a Linux OpenSUSE 11.2 system using an Intel Core i7 CPU 860 at 2.80 GHz with 8 GB of memory. In this simulation, stations using UGS and ertPS service flows generate a traffic of 64 Kbps. The rtPS stations generate MPEG-4 traffic with a 380 Kbps mean rate and 1.5 Mbps peak rate. The stations with nrtPS and BE flows generate data at a rate of 256 Kbps. The number of QoS service flows used is always equally distributed. The simulation time was 120 s and the bandwidth used was 20 MHz. Fig. 27 shows the simulation execution time in terms of station number. We can notice that the execution time increases linearly with the number of stations. This is due to the increase of the packet number generated by the stations. Note that although the PolyMAX module has full support for QoS classes and implements a complete scheduler with AMC, the simulation time remains reasonable. The coupling between the physical channel modeling and ns-2 also contributes to keeping the simulation time low.

6. Conclusions In this paper we presented the design and validation of the PolyMAX module for the ns-2 simulator. The module implements all five QoS classes with their particular grant-request mechanisms. Moreover, all the QoS parameters defined in the standard can be configured by the user. The designed scheduler is 802.16e compliant and supports different scheduling disciplines and manages an Adaptive Modulation and Coding mechanism. This simulation tool can be of tremendous help to researchers investigating Mobile WiMAX networks. It can be particularly useful for those working in scheduling design, QoS provisioning, modulation and coding and channel effective bandwidth estimation. As future work, we plan to improve the physical layer by adding packet errors, ARQ mechanisms, MIMO support, OFDMA, and a realistic wireless channel model. Acknowledgments This research project was supported by the Natural Sciences and Engineering Research Council of Canada under the Strategic Grant STPG365205.

S. Ben-Guedria et al. / Simulation Modelling Practice and Theory 19 (2011) 2076–2101

2101

References [1] IEEE standard for local and metropolitan area networks part 16: air interface for fixed broadband wireless access systems, IEEE Std 802.16-2004, 2004 (Revision of IEEE Std 802.16-2001). [2] IEEE standard for local and metropolitan area networks part 16: air interface for fixed and mobile broadband wireless access systems amendment 2: physical and medium access control layers for combined fixed and mobile operation in licensed bands and corrigendum 1, IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/Cor 1-2005, 2005 (Amendment and Corrigendum to IEEE Std 802.16-2004). [3] IEEE standard for local and metropolitan area networks part 16: air interface for fixed and mobile broadband wireless access systems, IEEE Std 802.16TM-2009 IEEE Standard for Local and metropolitan area networks, 2009. [4] M. Hayajneh, N.A. Ali, I. Khalil, Uplink and downlink scheduling for point to multipoint WiMAX networks, Wireless Communicaitons and Mobile Computing 9 (9) (2009) 1231–1242. [5] W.-H. Liao, W.-M. Yen, Power-saving scheduling with a QoS guarantee in a mobile WiMAX system, Journal of Network and Computer Applications 32 (6) (2009) 1144–1152. [6] N. Ali, M. Hayajneh, H. Hassanein, Cross layer scheduling algorithm for IEEE 802.16, in: Proceedings of the IEEE International Conference on Communications (ICC), 2008, pp. 3858–3862. [7] J. Song, J. Li, C. Li, A cross-layer WiMAX scheduling algorithm based on genetic algorithm, in: Proceedings of the 2009 Seventh Annual Communication Networks and Services Research Conference, 2009, pp. 292–296. [8] J. He, K. Guild, K. Yang, H.-H. Chen, Modeling contention based bandwith request scheme for IEEE 802.16 networks, IEEE Communication Letters 11 (8) (2007) 698–700. [9] M. Cao, W. Ma, Q. Zhang, X. Wang, W. Zhu, Modelling and performance analysis of the distributed scheduler in IEEE 802.16 mesh mode, in: Proceedings of the 6th ACM International Symposium on Mobile Ad hoc Networking and Computing (MobiHoc ’05), 2005, pp. 78–89. [10] T. Peyre, R. ElAzouzi, Performance analysis of single cell IEEE 802.16e wireless MAN, in: Proceedings of the 32nd IEEE Conference on Local Computer Networks (LCN ’07), 2007, pp. 262–263. [11] F. Wang, A. Ghosh, C. Sankaran, P. Fleming, F. Hsieh, S. Benes, Mobile wimax systems: performance and evolution, Communications Magazine, IEEE 46 (10) (2008) 41–49. [12] Ns-2 user information – nsnam, WWW, (accessed 06.05.10). [13] J. Chen, C.-C. Wang, F.C.-D. Tsai, C.-W. Chang, S.-S. Liu, J. Guo, W.-J. Lien, J.-H. Sum, C.-H. Hung, The design and implementation of WiMAX module for ns-2 simulator, in: Proceedings from the 2006 Workshop on ns-2: The IP Network Simulator (WNS2 ’06), 2006, p. 5. [14] C. Cicconetti, I.F. Akyildiz, L. Lenzini, WiMsh: a simple and efficient tool for simulating IEEE 802.16 wireless mesh networks in ns-2, in: Proceedings of the 2nd International Conference on Simulation Tools and Techniques (Simutools ’09), 2009, pp. 1–10. [15] National Institute of Standards and Technology, The network simulator ns-2: Nist add-on - ieee 802.16 model (mac+phy), 2009 (accessed 07.05.10). [16] J.F. Borin, N.L.S.D. Fonseca, Simulator for WiMAX networks, Simulation Modelling Practice and Theory 16 (7) (2008) 817–833. [17] J. Martin, M. Westall, S. Moser, A. Chowdhry, Docsis research project, 2005. [18] C.T.L. Inc., Data over cable service interface specifications, docsis 2.0. [19] N. Shrivastav, A network simulator model of the docsis protocol and a solution to the bandwidth-hog problem in cable networks, Master’s thesis, North Carolina State University, 2003. [20] W. Wei, H. Sharif, M. Hempel, Z. Ting, P. Mahasukhon, M. Tao, Implementation and performance evaluation of a complete, accurate, versatile and realistic simulation model for mobile wimax in ns-2, in: ICC 2010–2010 IEEE International Conference on Communications, Piscataway, NJ, USA, 2010. [21] X. Guo, R. Rouil, C. Soin, S. Parekh, B. Sikdar, S. Kalyanaraman, Wimax system design and evaluation methodology using the ns-2 simulator, in: 2009 First International Communication Systems and Networks and Workshops. COMSNETS 2009, Piscataway, NJ, USA, 2009. [22] D. LeGall, MPEG: a video compression standard for multimedia applications, Communications of the ACM 34 (4) (1991) 46–58. [23] B.-J. Kwak, N.-O. Song, L.E. Miller, Performance analysis of exponential backoff, IEEE/ACM Transactions on Networking 13 (2) (2005) 343–355. [24] A. Goldsmith, Wireless Communications, Cambridge University Press, New York, NY, USA, 2005. [25] F. Fitzek, M. Reisslein, Mpeg-4 and h.263 video traces for network performance evaluation, Network, IEEE 15 (6) (2001) 40–54. [26] S. Andreev, Z. Saffer, A. Anisimov, Overall delay analysis of ieee 802.16 network, in: Communications Workshops, 2009. ICC Workshops 2009, IEEE International Conference on, 2009, pp. 1 –6. [27] H. Eunju, J.-K. Kyung, A. Lyakhov, C.-D. Bong, Delay analysis of bandwidth request in truncated binary exponential backoff mechanism over error-free/ error-prone channels in ieee 802.16e, in: Quality of Service, 2008. IWQoS 2008, 16th International Workshop on, 2008, pp. 131 –138. [28] R. Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling, WileyInterscience, New York, NY, USA, 1991. [29] L. Nuaymi, WiMAX: Technology for Broadband Wireless Access, Wiley, 2007 (Chapter 5). [30] D. Pareit, V. Petrov, B. Lannoo, E. Tanghe, W. Joseph, I. Moerman, P. Demeester, L. Martens, A throughput analysis at the mac layer of mobile wimax, in: Wireless Communications and Networking Conference (WCNC), 2010 IEEE, 2010, pp. 1 –6. [31] A. Lie, J. Klaue, Evalvid-ra: trace driven simulation of rate adaptive mpeg-4 vbr video, Multimedia Systems 14 (1) (2008) 33–50. [32] General characteristics of international telephone connections and international telephone circuits, ITU-T Recommendation G.114, 2003. [33] M. Alasti, B. Neekzad, J. Hui, R. Vannithamby, Quality of service in wimax and lte networks, IEEE Communications Magazine 48 (2010) 104–111.