INDEXHABOUTHcopyright © samir amberkar

1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20

2.1

3.1
3.2
3.3
3.4
3.5




another knowledge site

3GPP Modem
Simulator


Test Your
Knowledge


another knowledge site


Base Station Scheduling

Scheduler Engine

Job of Scheduler Engine is to allocate resources from resource queues; resource queues are based on per bucket allocation requests (stored in Data Structures as shown in Fig 1.3).

After every Δt, Scheduler Engine traverses allocation request queues, starting from highest priority service queue (i.e. in order of HPVR, CR, and VR). At each allocation request, it evaluates "Allocation Criterion" for upcoming bucket (resource). If Criterion is satisfied, Scheduler Engine allocates the upcoming bucket to that particular User ID. If Criterion is not satisfied, Scheduler Engine moves to next allocation request. If all allocation requests have been visited, Scheduler does not allocate the bucket to anyone.

As can be seen, Scheduler Engine has Δt to traverse through allocation request queues. One way to make sure Scheduler Engine does not run out of time would be Scheduler Engine doing evaluations of "Allocation Criterion" in parallel (may be one thread/process per service queue).

Let us take an example to see clearly how this works.

Say currently, there are two users requesting allocations, one requesting { bearer of class CR with certain data rate } and the other requesting { bearer of class VR to transfer certain amount of data }. Say allocator converts this allocation requests to two internal per bucket allocation requests { User1 require a bucket every 7th Δt (i.e. every 7th bucket) } and { User2 require any 4 buckets }. Allocator puts User1 allocation request in CR queue and User2 allocation request in VR queue.

When Scheduler Engine wakes up (after Δt from last wake up call) - say or nth bucket, it first checks CR queue, finds User1 with allocation criterion as "every 7th bucket". As allocation criterion is satisfied, Scheduler Engine allocates the nth bucket to User1 and updates its allocation criterion as "every 7th bucket starting from nth bucket".

When Scheduler Engine wakes up for (n+1)th bucket, it checks CR queue - User1 allocation request. As (n+1)th bucket does not satisfy this allocation criteria and CR queue being finished, Scheduler Engine goes to VR queue and finds User2 request. Scheduler Engine allocates (n+1)th bucket to User2 and updates its allocation criterion as "require any 3 buckets".

So here is how resource allocation queue would look like this:

Bucket # User
n User1
n + 1 User2 (R3)
n + 2 User2 (R2)
n + 3 User2 (R1)
n + 4 User2 (E)
n + 5 -
n + 6 -
n + 7 User1
n + 8 -


Copyright © Samir Amberkar Page 4 of 5



I II III IV V