3.7.

Modified Largest Weighted Delay First (MLWDF)

In each time slot t, serve the queue j for which the following value is maximal
jWj(t)rj(t)
where Wj(t) is the head-of-the-line packet delay for queue j, rj(t) is the channel capacity with
respect to flow j, and j are arbitrary positive constants.It has been proved analytically in [4]
that The M-LWDF scheduling algorithm is throughput optimal. Moreover, the M-LWDF
scheduling rule remains throughput optimal if for all or some users, the delay Wj(t) is replaced
by the queue length (amount of data) Qj(t) .The key feature of this algorithm is that a scheduling
decision depends on both current channel conditions and the states of the queues. The M-LWDF
scheme is very easy to implement. The scheduler only needs to time stamp arriving data packets
of all users, or keep track of the current queue length. It is somewhat surprising that an algorithm
this simple can be throughput optimal: it is able to handle all the offered traffic, unless it is not
feasible at all. In addition, a choice of parameters i allows one to control packet delay
distributions for different users. Increasing the parameter i for user i, while keeping js of
other users unchanged, reduces packet delays for this flow at the expense of a delay increase for
other flows. Therefore, the delay distributions can be shaped.

Scheduling
FIFO
RR
WRR

Pros
Cons
Traffic Classes
Fast
and Unfair and cannot meet QoS requirement BE
Simple
Very simple
Unfair (variable packet size), cannot meet BE
QoS requirements
Simple

DRR/DWRR Simple
Priority
Simple

meets the throughput guarantee in Unfair BE

manner
supports variable packet sizes
BE
meets the delay guarantee Some ows BE
may starve, lower throughput

M-LWDF

Meet
the N/A
ertPS, rtPS and nrtPS
throughput and
delay
guarantee with
threshold
probability
Table 3.3 Pros and Cons of different scheduling algorithm
In this section, we provided an extensive survey of recent scheduling proposals for WiMAX and
discussed key issues and design factors. The scheduler designers need to be thoroughly familiar
with WiMAX characteristics such as the physical layer, frame format, registration process and so
on. The goals of the schedulers are basically to meet QoS guarantees for all service classes, to
maximize the system goodput, to maintain the fairness, to minimize power consumption, to have
as less complexity as possible and finally to ensure the system capability. To meet all these goals
is quite challenging since achieving one may require that we have to sacrifice the others.

Chapter 4
Proposed work
4.1. Problem Statement
Thus from the survey done, it clear that we have to see these things when developing scheduling
algorithm. That is Channel Aware bandwidth allocation, Support different classes of Service as
per QoS, Ability to maximise utilisation even in uneven traffic demand, Ability to meet
minimum traffic requirements as per class of service, Ability to sustain maximum traffic.
.

4.2. Proposed Scheduling Algorithm

In the survey carried at the previous chapter. It is found that m-lwdf algorithm is best suited for
real time traffic scheduling as it achieves the throughput and delay guarantee with threshold

probability. It carries all the real time traffic as shown is table discussed above. Therefore we are
going to take this m-lwdf algorithm and providing extension so that it meets the problem
statement described above.

4.3. Modified Largest Weighted Delay First (M-LWDF)

In each time slot t, serve the queue j for which the following equation is maximal
pWj(t)rj(t)
where
Wj(t) is the head-of-the-line packet delay for queue j,
rj(t) is the channel capacity with respect to flow j, and
p is arbitrary positive number by which individual services can be prioritized by the admistrater.

4.3.1. Max-Min Fairness Algorithm

In the, we assume that all MSs have infinite traffic to send and can use the resources allocated to
them. In other words, at scheduling stage all MSs always have packets waiting in their queues.
However, in practice, the available traffic is finite. Some MSs may not have enough traffic and
may not be able to use the fair share or some may have too much traffic. Our goal is to make a
fair allocation among MSs. In the case where some MSs can not use the fair share, their left-over
share should be fairly allocated to other MSs. This leads to the commonly used max-min
criterion for fair allocation. An allocation is said to be max-min fair if it maximizes the allocation
for the user that received the minimum. In Mobile WiMAX, the per-frame max-min fair
allocation can be derived as follow;
Maximize{Min(requested _ slots(i))}
Here, again requested_slots(i) is derived from the queue length and MCS for downlink for the
mobile station i. We use the MCS in order to derive the number of slots therefore finally each
MS with different MCS will get the fair share of the throughput. Fig. 4.1 shows steps in
computing the Max-Min fair allocation. First step is to compute the number of requested slots
from the number of bytes requested by an active mobile station and its MCS. Then, we sort the
requested slots for all active MSs in ascending order (Step 2). In step 3, for each active MS the
number of fair share slots is derived. Next, the number of granted slots, the minimum of number
of fair share and the number of requested slots, is updated. Then, the number of free slots is
updated. This loop continues until there are no more free slots or requested slots for all active
MSs have been satisfied.

Calculate #requested_slots/frame for each active MS given its MCS //1st step
Sort active MSs in ascending order of active_MS_requested_slots //2nd step
FOR each active_MSi //3rd step
Calculate #fairshare_slots for active_MSi
IF #requested_slotsi/frame < #fairshare_slots THEN
#fairshare_slotsi/frame = #requested_slots
END IF
Update #granted_slots for active_MSi
Update #free_slots and exit if #free_slots == 0
END FOR
FIGURE 4.1: Assigning slots
In the proposed method, the uplink bandwidth allocation at BS is done based on the per
connection requests from SSs. Because a SS may have multiple connections at the same time, the
bandwidth request messages should report the bandwidth requirement of each connection in SS.
After that the allocated bandwidth per connection is pooled together and granted to each SS.
Then SS re-distribute the received transmission opportunities among its connections according to
their QoS requirement. Therefore an additional scheduler is needed in each SS to reassign the
received transmission opportunities among different connections. Since the uplink traffic is
generated at SS, the distributed scheduler is able to arrange the transmission based on the up-todate information and then provide tight QoS guarantee for its connections.Since the BS scheduler
has limited information on the traffic generated at SS, the computing of bandwidth allocation
should just consider the bandwidth request and reservation for each connection. Let BWMINi
denote the minimum reserved bandwidth for connection i, and BWREQi represent the bandwidth
currently demanded by the connection i. Since the connection will never get more resources than
it has requested, the bandwidth actually allocated (BWALLOCATEi) during this phase is
BWALLOCATEi = min {BWMINi, BWREQi}
For rtPS and nrtPS, BWMINi is specified by the QoS parameter termed Minimum Reserved
Traffic Rate. Clearly, to guarantee the contracted bandwidth, the sum of minimum reserved
bandwidth for all the connections should not exceed the available bandwidth B. After each
connection gets its guaranteed bandwidth, if there is still excess uplink bandwidth remained, BS
scheduler should distribute the residual bandwidth in proportion to the pre-assigned connection
weight. The algorithm in this phase can be described as:
BWREMAIN = B - BWALLOCATEi;
i
While BWREMAIN > 0
{
If (BWALLOCATEi < BWREQi)
{

n
BWADDi = BWREMAIN*Wi / Wk;
k=1
BWALLOCATEi = BWALLOCATEi + BWADDi;
BWREMAIN = BWREMAIN - BWADDi;
}
}
Where BWREMAIN is the remaining bandwidth, BWADDi is the amount of excess bandwidth
allocated to connection queue i and Wi is the weight of connection queue i. Now the allocated
bandwidth per connection is pooled together and granted to each SS.SS scheduler will select the
packet to be transmitted from the highest priority queue. The traffic rates have fixed in the
schedulers as below table. And the priority of the queue is maintained in the following way
UGS > rtPS > nrtPS > BE.