GSOC2009WimaxUplinkScheduler

From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

General

The ns-3 WiMAX module lacks the implementation of a more sophisticated uplink scheduler for QoS provisioning. The main goal of this project is to port the uplink scheduler implemented in the ns-2 WiMAX module developed by the Computer Networks Laboratory [1] at University of Campinas to the ns-3 WiMAX module.

The second goal of this project is to implement propagation and error models to allow the simulation of more realistic scenarios.

Project Background

To support multimedia applications, the IEEE 802.16 standard defines five types of service flows (UGS, ertPs, rtPS, nrtPS and BE), each with different QoS requirements. However, the scheduling mechanism is left to be defined by proprietary implementations. Many scheduling algorithms for the IEEE 802.16 standard have been proposed in the literature, and one of them, proposed in [2], is implemented in the WiMAX module [3] developed for the ns-2 by the Computer Networks Laboratory (LRC - [4]) at University of Campinas. The ns-3 WiMAX module implements a FCFS scheduler and, therefore, it lacks the implementation of a more sophisticated scheduler for QoS provision. The scheduler is responsible by the resource allocation and, consequently, is fundamental for the QoS provision. While the downlink scheduling requires one scheduler in the base station, uplink scheduling needs two components, one in the base station and one in the subscriber station. The base station uplink scheduler allocates bandwidth to subscriber stations and the subscriber station scheduler defines which packets will be sent in the received grants.

In this project, a more sophisticated uplink scheduler to support the QoS requirements of multimedia applications will be implemented. The recent WiMAX module for ns-2 developed by LRC[5] supports bandwidth allocation and scheduling services. The uplink and the downlink scheduler developed by LRC will be ported to the ns-3 WiMAX module.

As secondary goals, propagation and error model for ns-3 will be implemented. These models can bring more realism to the module, with throughput and error rate closer to reality. Theses models may reflect the sub-urban environment of WiMAX networks.


Approach

Primary goal

  • To port the uplink scheduler developed by LRC to the ns-3:

The uplink scheduler developed by LRC will be ported to ns-3. The existing scheduler uses three queues, which are the low priority queue, the intermediate queue and the high priority queue. The scheduler servers the queues in strict priority order. UGS grants are stored in high priority queue. nrtPS and rtPS bandwidth requests are stored in the intermediate queue, but they can migrate to the high priority queue to have their QoS requirements satisfied. And the low priority queue stores the bandwidth requests of the BE service flow. In this project, I will port the uplink scheduler developed by LRC to ns-3.

To feed the queues I will need to access some information in the bandwidth request messages, such as which connection has sent the request, how much bandwidth it is requesting, and with which type of service it is associated. Moreover, I will have to learn how to include the scheduling agenda in the UL-MAP message, which is transmitted by the base station to the subscriber stations at the beginning of each frame.

According to [3], the bandwidth requests and the UL-MAP transmission is already implemented. So my work will consist in getting information from the bandwidth request messages for the scheduling process and sending the scheduling result through the UL-MAP messages. The FCFS scheduler implemented in the ns-3 WiMAX module will be replaced by the one implemented in [1].

At the ns-3 WiMAX module, the uplink scheduler is implemented in the UplinkScheduler::Schedule() and in the UplinkScheduler::ServiceUnsolicitedGrants methods. So, the scheduler code implemented in [1] will be ported to these methods. The information required to feed the scheduler queues will be provided by the bandwidth manager of the ns-3 module through the BandwidthManager::ProcessBandwidthRequest method. The scheduling result will be included in the UL-MAP through the UplinkScheduler::AddUplinkAllocation, which is already implemented.


  • Tests and Validation:

To be sure that the implemented scheduler is providing the requested QoS, I will run several validation tests for different scenarios and verify if the scheduler can provide fair bandwidth sharing among flows in the same service level. Moreover, I will verify whether the scheduler provides the maximum delay requirement for UGS and rtPS connections and the minimum rate requirement for rtPS and nrtPS connections as well as whether the BE traffic is not being starved. By simulating scenarios with different service levels and ranging the number of nodes, it will be possible to check whether the scheduler is providing the expected QoS.

To get a stable module, I intend to run many tests, white and black box tests. The current ns-3 regression test also must pass.

Secondary goals

  • Propagation and error models implementation:

In order to archive a more realist simulator, I propose to implement propagation and error models for ns-3. The propagation models appropriated for WiMAX sub-urbans environments are SUI, COST231 and TU-6. AWGN noise can be implemented and it is possible to find the SNR (Signal to Noise Ratio). With an error model, like YANS (Yet Another Network Simulator), we find the BER/PER and a packet is dropped according to this PER value. I will implement SUI and COST231 model for propagation model, AWGN for noise model and YANS for error model. This features must be easy to change and must be configurable by C++ script.

I will implement a new class, for example SUIPropagationLossModel. The models will be connected and will be chose at WiMAX Channel. The error model will be connected to WiMAX PHY. It will be necessary severals modifications at WiMAX PHY and WiMAX Channel in order to support these models.

To validate these models, I will compare the results to theoretical values and also with other results from literature.

  • ertPS service implementation:

The current WiMAX module for ns-3 is compliant with the IEEE 802.16-2004 standard and it does not include ertPS service flow specified in the IEEE 802.16-2005 standard, which is an amendment to the IEEE 802.16-2004 standard. I will add this new service flow to the ns-3 module and adapt the scheduling mechanism for such service.

Schedule

Uplink Scheduler

  • Plan and implement simulation scripts. (OK)
  • Recover QoS information and bandwidth request information. (OK)
  • Plan queue struct. (OK)
  • Implement priotity queues. (OK)
  • Schedule jobs of queues. (OK)
  • Implement method to garantee delay requeriments. (OK)
  • Implement method to garantee bandwidth requeriments.
  • Implement simulation scripts to validate scheduler.

Propagation model

  • Implementation of sui-propagation-loss-model/cost231-propagation-loss-model.
  • Implementation of Noise class.
  • Adaptation of yans error model with correct params for WiMAX PHY layer.
  • Implement simulation scripts to validate error model.


ertPS flow

  • Implementation of ertPS flow.
  • Adaptation of scheduler to suport ertPS flow.
  • Implement simulation scripts to validate ertPS flow and scheduler.