|
|
|
|
|
|
Would this algorithm work fine for all scenarios ? The answer is "No". Let's add another User3 in above example and see if the Scheduler Engine behaves well enough. Say User3 request VR bearer to transfer certain amount of data. Say allocator convert this request to internal per bucket allocation request { User3 require any 8 buckets } and puts it into VR queue.
Scheduler Engine would give nth bucket to User1, User1 being in CR queue). (n+1)th bucket goes to User2 and that is also OK. The problem is to which user (n+2)th bucket should go, User2 or User3. Both are in same queue, but User2 being ahead of User3 in queue will get allocation. Though service requirements would be met for all users, it is not fair to User3.
Above Scheduler Engine logic can be made "fair" by converting allocation request queue for VR queue from linear to circular with (allocation request) pointer advancing after every allocation to next allocation request. With this enhancement, allocation queue would look like this:
| Bucket # |
User |
| n |
User1 |
| n + 1 |
User2 (R3) |
| n + 2 |
User3 (R7) |
| n + 3 |
User2 (R2) |
| n + 4 |
User3 (R6) |
| n + 5 |
User2 (R1) |
| n + 6 |
User3 (R5) |
| n + 7 |
User1 |
| n + 8 |
User2 (E) |
| n + 9 |
User3 (R4) |
| n + 10 |
User3 (R3) |
| n + 11 |
User3 (R2) |
| n + 12 |
User3 (R1) |
| n + 13 |
User3 (E) |
| n + 14 |
User1 |
| n + 15 |
- |
Note that we have taken an example of CR and VR combination without HPVR. Addition of HPVR would cause problem to CR as HPVR being of more priority than CR may just eat up CR's share !!
Conclusion
We attempted a logical incremental solution to resource scheduling based on very few protocol parameters. On one hand, we have number of protocol parameters to consider, on the other hand, field keep on presenting different scenarios/combinations in terms of users and bearers/services. Eventually, algorithm is to be evaluated on another set of parameters like fairness, faithfulness, and efficiency in actual fields at various locations.
|
|
|
|
|
|
|
|
|
|
|
