Scheduler Options for ITM

1. Scheduler Options for ITM Matthew Andrews, Alexander Stolyar, Colin Kahn February 11, 2008

2. Scheduler Modeling for ITM • Problem Statement: • What smart things can we do with the scheduler to trade off capacity against QoE so that ITM can be made more efficient? • Quantify the QoE and capacity differential. • Necessary to support flexibility in cost/subscriber in business case. • Ground Rules: • To facilitate implementation, we don’t want to change the Qualcomm scheduler, only change parameters associated with the scheduler. • Background: • EV-DO RevA Scheduler has “recommended settings” provided by Qualcomm for various service classes. • ~16 parameters in total, but “Target Throughput”, “GoS Factor” and “QoSMetricState” are main parameters to adjust. • Optimization for Capacity seems to be an afterthought.

3. Scheduler Optimization • Focus on adjusting the GoS_Factor • Subscribers/Applications receive FL slot utilization proportional to the GoS factor. • GoS is set at “2” and “7” for the two users in the ITM Video Demo. • Avoids AT interoperability issue with setting up a separate RLP Flow that was observed in Lab Testing by Rich O’Sullivan/Mike Turner. • Instead of fixing the GoS, adjust it according to the DRC (Data Rate Control) reported by the AT. • Reflects the RF environment of the AT. • Gives a boost only to ATs that really need it (eg: because of poor RF). • Choice of appropriate threshold will be application dependent

4. Illustrative Example - Affect of Adjusting the GoS Without ITM ITM Policy: Boost FL Scheduler priority by 2x for high priority users whose DRC < 1 Mbps With ITM High Priority Apps./ Users - - Low Priority Apps. / Users Rate Distribution High Priority Apps./ Users - Rate Distribution Curve Shift: High Priority Apps / Users get higher FL rates. User Throughput (bps) Due to Subscriber geometry, most high priority users happen to have lower throughput than low priority users. User Throughput (bps) Low Priority Median = 67 kbps High Priority Median = 57 kbps Low Priority Median = 57 kbps High Priority Median = 65 kbps Simulation parameters: 20 Users, 11 Low Priority, 9 high priority. Based on EV-DO Rev0 DRC data.

5. Setup 1: Simulation • 20 users • 11 low priority, 9 high priority • GoS factor = 2 for high priority/low geometry users • DRC values taken from Rev0 field trace • threshold for bad/good geometry user • 0, 100, 300, 600, 1000, infinity (kbps) • Plot cdf of rate distribution for high/low priority users

6. thresh = 0kbps thresh = 100kbps

7. thresh = 300kbps thresh = 600kbps

8. thresh = 1000kbps thresh = infinity

9. Setup 2: Simplified analytic model • 8 Users • 4 high priority, 4 low priority • GoS boost for high priority users is 2x • DRC values are random, uniformly distributed between 0 and 1600

10. Relative FL Total Throughput vs DRC Threshold • A DRC threshold of 1000 kbps drops the total throughput by only ~9%

11. User Throughput • At DRC=1000 kbps, a low priority subscriber’s rate drops ~25%, (100 kbps to ~75kbps) All high priority users get a boost

12. Relative Throughput Increase • Throughput ranges from ~1.4x to 2x for high priority users receiving a boost. • Throughput ranges from 1x to ~0.7x for users not receiving a boost. • Significant factor is the number of users receiving a boost compared to total number of users.

13. Setup 3: Simulation • 20 users • GoS factor = 2 for high priority users • DRC values taken from Rev0 field trace • No DRC threshold – all high priority users have increased GoS • Number of high priority users: • 1, 2, 4, 8 • Plot cdf of rate distribution for high/low priority users

14. 1 high priority user – no ITM 1 high priority user – with ITM

15. 2 high priority users – no ITM 2 high priority users – with ITM

16. 4 high priority users – no ITM 4 high priority users – with ITM

17. 8 high priority users – no ITM 8 high priority users – with ITM

18. Summary • A DRC threshold for boosting a users rate is a useful knob. • Targets rate boots to users that really need it. • Minimizes affect on lower priority users that are not getting a boost. • Is something that is well outside the realm of core network capability • Helps with discussions with Starent. • Should be considered for inclusion in ITM product plans. • Challenge will be to finding appropriate settings for the DRC threshold since it will be application dependent.