NETWORK ASSISTED RATE ADAPTATION FOR CONVERSATIONAL VIDEO OVER LTE CSWS 14

Transcription

1 NETWORK ASSISTED RATE ADAPTATION FOR CONVERSATIONAL VIDEO OVER LTE CSWS 14 {Ylva.Timner, Jonas.Pettersson, Hans.Hannu, Min.W.Wang,

2 Endpoint based rate adaptation Examples Google Congestion Control (GCC) Self-clocked rate adaptation (SCReAM) Bandwidth is estimated based on delay and/or packet loss Path capacity is probed endpoint endpoint AB 2014 Page 2

3 Endpoint based rate adaptation Issues Difficult to precisely determine congestion Over-reaction to handover Over-reaction to congestion Negative impact from other cross traffic Frequent (and large) bitrate changes Network service optimizations congestion may become invisible to end users Fairness between users difficult to achieve AB 2014 Page 3

4 Network assisted rate adaptation Rate adaptation algorithm placed close to the air interface bottle neck A session controller is in control of the bitrates network assisted endpoint endpoint AB 2014 Page 4

5 Network assisted rate adaptation Two algorithm alternatives examined: Bitrate fair Resource fair Network assisted rate values can be conveyed in RTP header extensions (RFC5285) or in RTCP application layer feedback messages (RFC4585) framework can complement an endpoint based solution RRC signaling can be used to forward the bitrates to the session controller or directly to the terminals. AB 2014 Page 5

6 Bitrate fair All video users in a cell get the same rate A utilization target (e.g. 80%) controls the resource split between video and other users high cost low cost a b c constant bitrate (bitrate fair) AB 2014 Page 6

7 Resource Fair (proportionally fair) All users (regardless of service) should get their fair share of the radio resources a b c bitrate AB 2014 Page 7

8 LTE scheduling basics The scheduler allocates transmission resources to bearers (users) Scheduling interval: 1ms A scheduling weight controls the likelihood that a bearer gets transmission resources Different scheduling algorithms Proportional fair Delay (optimized queuing delay) AB 2014 Page 8

9 Scheduling weight Scheduling weight Bearer Configurations FTP on best effort bearer: Proportional fair Conversational bearer: Delay scheduling Proportional fair Delay Bitrate Queuing delay AB 2014 Page 10

10 Bitrate fair algorithm Adaptation based on channel utilization measures: CU P : video traffic + tcp traffic. CU HP : retransmissions + video packets above delay threshold Flowchart is executed every 100ms or when users enter or leave the cell Yes Reduce rate quickly R new = R old (1 + (Max hp / CU hp 1)) Yes Send rate change command to all video users in cell CU hp > Max hp R new - R old / R old > Th No No Change rate smootly R new = R old (1 + α (Max p / CU p 1)) Done AB 2014 Page 11

11 DL utilization TX bitrate [kb/s] Received packet delay [s] >18 s : low CU, ramp up rate s good utilization Delays are rising at 21s Detected by High CU HP Bitrate fair example Total Channel utilization Utilization, CU P High priority Prio CU, transmissions CU HP time [s] Recommended rate in cell time [s] Used rates per Video user Recommended Rate in Cell time [s] AB 2014 Page 13

12 DL utilization TX bitrate [kb/s] Received packet delay [s] Bitrate fair example Low CU Increase Rate Good CU Keep Rate Delays rising, High CU HP Decrease Rates fast Total Channel utilization Utilization, CU P High priority Prio CU, transmissions CU HP time [s] Recommended rate in cell time [s] Used rates per Video user Recommended Rate in Cell time [s] AB 2014 Page 15

13 Resource fair algorithm Determine target utilization u (equal split): 1 u = N video +N other Use measured channel quality (potential rate) to determine target rate, R, for each user i : u i = R i Q i R i = u Q i A closed loop part complements with compensation for possible estimation errors AB 2014 Page 16

14 Requested bitrate [kb/s] Connected users Resource fair example Rate changes Ability to keep fairness target video users TCP users time [s] time [s] 0.4 Actual utilization Wanted utilization time [s] AB 2014 Page 17

15 active users Simulation scenario 21 cells, 3GPP Case 1, 5 MHz Conversational video: 150 kbps 1500 kbps Other traffic: Small file download 2 Mbit/s/cell cell 8average video cell 0 video cell 7average ftp cell 60 ftp Example: Average 6 video users/cell time [s] AB 2014 Page 18

16 average codec rate [kbps] Bitrate Resource fair achieves the highest average bitrate among the network assisted rate adaptation algorithms but is more conservative than endpoint solution at high load Self clocked rate fair resource fair fixed 150 kbps fixed 300 kbps video users/cell AB 2014 Page 19

17 delay percentile-of-percentile [ms] Latency Both network assisted algorithms manages to ensure low latency even at high load levels Self-clocked algorithm works well only at lower load levels Self clocked rate fair resource fair fixed 150 kbps fixed 300 kbps video users/cell AB 2014 Page 20

18 Conclusion Flexible way to distribute system resources between conversational video and other best effort traffic Fairness between users can be controlled The use of delay schedulers : Gives very low latency regardless of load Increased grace time upon congestion Precise discrimination between congestion and other noncongestion related impairments AB 2014 Page 21

19 AB 2014 Page 22

20 Resource fair closed loop part Add a correction factor γ to the open loop: R i = u Q i 1 + γ Compute expected utilization: U video = otherwise N video N video +N other if unlimited rates, limit(r i ) Q i (1+γ) Adapt γ based on the relative error versus the measured utilization Ûvideo : e = U video U video γ k = γ k 1 + K p 1 + Δ T i e k e k 1 AB 2014 Page 25

21