MONITORED PERFORMANCE PARAMETERS

The simulation campaign has the aim of assessing the scheduling framework behavior in terms of both (1) class-based QoS differentiation capability and fair share of the channel bandwidth and (2) fairness in the treatment of traffic flows in the same class. The monitored performance parameters are the following:

§  Throughput: represents the achieved bit rate for a given traffic flow, accounting for the totality of packets delivered at the target SS. The totality of delivered packets include both useful and unuseful packets. Unuseful packets are either errored or expired packets.

§  Goodput: represents the achieved bit rate for a given traffic flow, accounting for the successfully delivered packets at the target SS. Successfully delivered packets are those packets received without errors and within the maximum tolerated latency. The goodput index intrinsically accounts for both packet losses and delays.

§  Average latency: is the delay accumulated by packets of each flow from their arrival time at the BS to the delivery time at the target SS.

§  Total packet loss percentage: accounts for packet losses occurred both at the BS, due to deadline expiration of queued packets waiting for an error-free channel, and at the receiving SS due to channel errors or to the reception of over-delayed packets.

PERFORMANCE MEASUREMENTS FOR WiMAX NETWORKS

It has been noted that, at the time of writing, there is not much published work available regarding real-life performance evaluation of WiMAX networks. However, some of the currently available literature will be briefly described in this section.

WiMAX test-bed based results for measurements in the field have been reported. The Alvarion test bed, BreezeMax http://www.alvarion.com/, operating in the 3.5 GHz licence band and fully IEEE 802.16-2004 compliant, has been employed for measurements. Experimental data has been collected for four nodes operating in PMP mode in a rural residential environment. A sectorial antenna with a gain of 14 dbi, covering all three SS (FDD half duplex), has been deployed. All nodes run using a Linux distribution and are attached to WiMAX equipment through the Ethernet. Data flow and CBR VoIP are generated by the freely available tool known as D-ITG, http://www.grid.unina.it/software/ITG/;

It has been observed that the performance of a G.711 codec is far too low to be acceptable and SS cannot support more than two high quality calls. The G.723.1 codec outperforms G.729.2. It has been pointed out that UL measurements contradict simulation results and its earlier version, where larger delays in UL are ascribed to bandwidth request mechanisms and PHY overhead. Due to activation of piggybacking for bandwidth reservation. It has also been pointed out that the R-factor, E-model, needs to be considered for scheduler design, though, nothing has been mentioned about the type of scheduler that was being used at SSs and BS during the test-bed measurements.

Recently, a performance study of UL Scheduling algorithms for PMP WiMAX has been carried out. It has studied major scheduling algorithms using the NS-2 simulator. Also, it provides pseudocode for various schedulers in a simple and accessible manner. The existing scheduling mechanisms have been divided into three categories: homogenous, heterogenous, and opportunistic types. It has been reported that EDF and (EDF+WFQ+FIFO) result in the lowest average delay for rtPS and ertPS; WRR, WFQ, and (EDF+WFQ) provide a fair distribution of bandwidth; the (EDF+WFQ) hybrid setup is fairer than (EDF+WFQ+FIFO). In addition, it has been concluded that most of the legacy schedulers are not very suitable for WiMAX applications. However, WFQ, cross-layer, and queueing theoretic-based schedulers are seen to be promising candidates for applications in a WiMAX network.

Simulation Analysis | Performance Evaluation

We now evaluate the impact on the performance of VoIP, VC, and VoD traffic, in terms of the jitter, with respect to the number of SSs (N) and the frame duration. We assume that each SS has only one connection, which carries exactly one traffic source of the specified type (i.e., one of VoIP, VC, or VoD).

We start assessing the performance of QoS traffic by setting up a scenario with a variable number of SSs ranging from 5 to 43, with a frame duration of 10 msec. Only one SS is provisioned with a VoD connection, whereas the remaining is partitioned between VoIP and VC traffic evenly. We repeated the scenario with both the MPEG4 and the H.263 trace files for VC traffic. The jitter of DL connections is reported in Figure 1. As can be seen, when the network is underloaded (i.e., N ≤ 27) the jitter is always smaller than the interarrival time of packets of each traffic source. As the number of SSs further increases, the VoD curves increases steeply. In fact, with a high offered load, the VoD traffic performance degrades because the rate provisioned for the VoD connection is equal to the mean rate of the application. This results in the performance of VoIP and VC connections being isolated from that of VoD traffic. Note that this has been achieved without enforcing a strict priority between rtPS and nrtPS connections, which are served by the same instance of the DRR schedulers.

Figure 1: Jitter of downlink connections versus number of Subscriber Stations, with different videoconference codecs.

Additionally, the VC codec significantly impacts on the performance. In particular, with N < 35, in the case of H.263, the jitter results slightly higher than that of the VoD source whereas the MPEG case exhibits a lower jitter. This can be explained as follows. H.263 codecs produce frames at variable time intervals. Therefore, the VC connection queue can potentially become idle due to inactivity periods. As soon as the queue becomes backlogged again, it is reinserted at the tail of the DRR list of connections waiting to be served. Therefore, the new arrived packet has to wait until all the other connections have been served, which increases the jitter. Such a situation is less likely to happen with the MPEG4 codec because video frames are generated at fixed time intervals, with no inactivity periods.

With regard to the UL connections, results are reported in Figure 2. As expected, the jitter is higher than that in the DL case, because UL connections experience the additional delay of notifying the BS of their bandwidth requests. However, the curves are almost constant when the offered load increases (except for the H.263 VC case), because the BS schedules unicast polls on a periodic basis, with the period equal to the interarrival time of SDUs of each connection. The anomaly of the H.263 curve with respect to VoIP and VC-MPEG4 is due to the variable interarrival of video frames. In fact the transmission queue of a H.263 connection can potentially become idle when polled from the BS. Hence, a connection that misses the poll then needs to wait an entire polling interval before it will have a subsequent chance to send a bandwidth request.

Figure 2: Jitter of downlink connections versus number of Subscriber Stations, with different videoconference codecs.

Finally, we setup a scenario with VoIP and VC-MPEG4 traffic only, where N ranges between 5 and 45, and with variable frame duration. The jitter of UL connections is reported in Figure 3. As can be seen, the longer the frame duration, the higher are the curves. This can be explained as follows. As scheduling is performed at the beginning of each frame, the higher the frame duration, the longer (on average) an SS has to wait before using its grant. In other words, with longer frames the BS is less responsive to the SSs' bandwidth requests. Similar considerations also hold for the DL case, where an SDU received by the BS has to wait at least until the next frame (i.e., the transmission of the next DL-MAP) before it can be served.

Figure 3: Jitter of uplink connections, both Voice over IP and videoconference, versus number of Subscriber Stations, with variable frame duration.