SLA-Aware Adaptive On-Demand Data Broadcasting in Wireless Environments

1. SLA-Aware Adaptive On-Demand DataBroadcasting in Wireless Environments Adrian Daniel Popescu, Mohamed A. Sharaf , Cristiana Amza MDM 2009

2. Outline • Introduction • Motivation • System model • Tardiness-aware scheduling -- SAAB-T • Utility-aware scheduling -- SAAB-U • Experiments • Conclusions

3. Introduction • in a dynamic mobile environment motivated us to use Service Level Agreements (SLAs) where a user specifies the utility of data as a function of its arrival time. • SLAs provide users with the flexibility to define the utility of delayed data • Broadcasting • Pull-based(on-demand) • Push-based

4. Introduction • On-demand data broadcasting • More scable • users submit requests for data items of interest and the broadcast server aggregates requests for the same data item and broadcasts it only once. • If a data item is highly popular, then broadcasting that data item to all interested users substantially reduces the number of transmissions.

5. Motivation • optimizing response time is not sufficient to maximize data usability since it overlooks the user’s requirements and expectations • SLA-aware adaptive data broadcast (SAAB) scheduling policy for maximizing the system utility under SLA-based performance measures • minimizing response time or drop rate

6. System model • on-demand data broadcasting environment

7. System model • Request • 1) Data Item (Ii): which is the data item corresponding to request Ri, • 2) Arrival Time (Ai): which is the point of time where request Ri is issued, and • 3) Deadline (Di): which is the soft deadline associated with request Ri.

8. System model • Scheduling Queue • 1) Service Time (Cj ): is the time required for transmitting data item Ij on the downlink channel • 2) Popularity (Pj ): is the number of pending requests for data item Ij , and • 3) Requests Vector (Rj ): is a requests vector of length Pj , where each entry in Rj corresponds to one of the Pj pending requests for Ij (i.e., Rj = Rj1 Rj2 … RjPj )

9. Tardiness-aware scheduling -- SAAB-T • there is some pending request Rx for that data item Ix with deadline Dx • Slack : • assume two data items I1 and I2 • schedule of choice (1)X I1 first,then I2 (2)Y I2 first,then I1

10. Tardiness-aware scheduling -- SAAB-T • Under schedule X • Assume that the number of these requests is P1,def , where 0≤ P1,def ≤ P1. • The sum of all requests which currently have a negative slack, S1,j • tardiness of requests for item I1

11. Tardiness-aware scheduling -- SAAB-T • Assume that the number of these requests is P2,def , where 0≤ P2,def + P2,add≤ P2 • The sum of all requests which currently have a negative slack, S2,j • Pending requests to I2 had positive slack when the scheduling decision was made but that slack became negative • tardiness of requests for item I2

12. Tardiness-aware scheduling -- SAAB-T • total tardiness under schedule X and Y

13. Tardiness-aware scheduling -- SAAB-T • Example: • C1 = 5, C2 = 10 T1x = -(-2)=2 T2x=-(-3-5)+(5-3) =10 Tx = 12 T1y = -(-3-5)=8 T2y=-(-2)+(10-3) =9 Ty = 17

14. Tardiness-aware scheduling -- SAAB-T • If Tx < Ty, • priority:

15. Utility-aware scheduling -- SAAB-U SLA -- Utility function SAAB-U -- Utility function

16. Utility-aware scheduling -- SAAB-U • each request for I2 is delayed by the amount of time needed to transmit I1 • general priority function

17. Experiments SJF = 1/Ci high load EDF = 1/Di low load MRF = Pi W-SJF = Pi/Ci • SAAB-T • Slack factor (SF)

18. Experiments • SAAB-U

19. Conclusions • This request aggregation is efficient since it allows for fewer data broadcasts which saves bandwidth and reduces delays. • minimizing response time, or drop rate • SAAB is highly sensitive to workload conditions