Content Streaming for Mobile Environments

Transcription

1 Content Streaming for Mobile Environments Mahbub Hassan and Salil Kanhere School of Computer Science and Engineering The University of New South Wales, Sydney, Australia {mahbub,

2 Outline Introduction and motivation Traditional server-controlled streaming HTTP-based client-controlled streaming Motivations Commercial solutions Standardization Client intelligence Streaming Optimization for Fast Moving Users Geo-sensitivity of network performance Geo-intelligent streaming Content distribution for fast moving users Conclusions 11 June

3 Introduction and Motivation

4 Mobile Internet Data Tsunami Mobile subscribers grew from 500 million in 1999 to 5.3 billion in July 2011 One in 5 global subscribers have access to high-data rate mobile connectivity (3G or better) Significant percentage of subscriber base (USA: 25%) ONLY uses mobile connectivity to access the Internet Mobile Internet access is expected to overtake fixed connectivity Already true in some countries such as China Cisco estimates 26x increase in mobile data usage by June

5 Mobile Streaming on the rise Audio/video streaming is being increasingly used by commuters to access news, information & entertainment Audio: Internet Radio, Amazon Cloud Player, Spotify, Video: Youtube, Justin.tv, Netflix, Hulu, BBC iplayer,. Video streaming is the fastest growing application and accounts for over 1/3rd of mobile Internet data globally 11 June

6 Mobile Streaming on the rise Source: Allot Communications Mobile Trends Report, H2, 2010 Youtube accounts for nearly 50% of mobile video streaming traffic and 17% of overall mobile data traffic Jan 2011: Mobile Youtube streaming hits 200 million/day 11 June

7 Streaming One way to watch video content is to download the entire content before playing it at the receiver Long delay (nearly 3 minutes to download a 10MB video at 500 Kbps) A better option is to allow playing while the content is being downloaded this is called streaming Streaming is very popular with mobile users who want to watch news or sports updates on the go 11 June

8 Cumulative data Streaming Multimedia: What is it? 1. video recorded 2. video sent network delay 3. video received, played out at client time streaming: at this time, client playing out early part of video, while server still sending later part of video 11 June

9 Basic Principle of Streaming Buffering at the receiver Start playout only when the buffer is filled up with x- sec of video Prevents buffer underflow or video freezing during unexpected network problem However, the larger the x, the longer the user waits before the video can start Usually the start-up delay is configured to be only a few seconds Extreme case download full content before playing (OK for short clips only) 11 June

10 Client Buffering Cumulative data constant bit rate video transmission variable network delay client video reception buffered video constant bit rate video playout at client client playout delay time client-side buffering, playout delay compensate for network-added delay, delay jitter 11 June

11 Client Buffering variable fill rate, x(t) constant drain rate, d buffered video client-side buffering, playout delay compensate for network-added delay, delay jitter 11 June

12 HTTP Streaming browser GETs metafile browser launches player, passing metafile (content type HTTP header indicates the type of file) player contacts server server streams audio/video to player 11 June

13 Streaming from a streaming server allows for non-http protocol between server, media player UDP or TCP for step (3) 11 June

14 Streaming Quality and its relationship to transmission time or bandwidth requirement Video has many frames per second Each frame is digitized, coded, or compressed with certain parameters Higher the compression, the lower the storage requirement for the video, the worse the quality of the frames (and vice versa) More bits per frame (or content chunk ) means longer it takes to download or more bandwidth is needed to maintain the same download time for a given frame or chunk 11 June

15 Non-adaptive streaming The coding quality is chosen once at the beginning and remains the same throughout the streaming In the past, the user would choose from several different qualities based on Internet access types (low quality stream for 64-kbps modem, higher for ADSL, for example) 11 June

16 Problems with non-adaptive streaming Network bandwidth is variable If you select a stream quality suitable for a 1-Mbps network connection, there may be problems if the network bandwidth falls below 1-Mbps A frame may not arrive at the receiver in time to play it Or, if you select lower quality for a cellular connection, but move to WiFi coverage later, you miss out high quality video opportunity Non-adaptive streaming therefore delivers nonoptimized user quality of experience (QoE) 11 June

17 Adaptive Streaming Monitor network condition and dynamically switch video quality to adapt for bandwidth variation Reduces risk of buffer underflow and allows for continuous playback under fluctuating network conditions Ensures higher quality video on average (can optimize user experience) A great success and is widely embraced by the industry 11 June

18 Traditional Server-controlled Streaming

19 Generic Architecture for Server-Controlled Adaptive Streaming Server stores multiple streams for the same content, where each stream is encoded with a different quality (different bandwidth requirement) Client monitors network bandwidth and provides regular feedback to server Server uses specific adaptation intelligence to switch between streams based on client feedback 11 June

20 Protocols for Server-Controlled Adaptive Streaming Real-time transport protocol (RTP) is an IETF standard for transmitting audio/video over IP-based networks Real-time transport control protocol (RTCP) is a companion protocol for the server to collect regular network feedback (e.g., packet loss rate) from the client The server receives reports from the client typically every 5 seconds or so and switches to different stream quality according to some rate adaptation algorithm Real-time Streaming Protocol (RTSP) is a control protocol that allows user control of streaming media rewind, fast forward, pause, resume, repositioning, etc 11 June

21 Real-Time Protocol (RTP) RTP specifies packet structure for packets carrying audio, video data RFC 3550 RTP packet provides payload type identification packet sequence numbering time stamping RTP runs in end systems RTP packets encapsulated in UDP segments interoperability: if two Internet phone applications run RTP, then they may be able to work together 11 June

22 RTP runs on top of UDP RTP libraries provide transportlayer interface that extends UDP: Port numbers, IP addresses Payload type identification Packet sequence numbering Time-stamping 11 June

23 RTP Example consider sending 64 kbps PCM-encoded voice over RTP. application collects encoded data in chunks, e.g., every 20 msec = 160 bytes in a chunk. audio chunk + RTP header form RTP packet, which is encapsulated in UDP segment RTP header indicates type of audio encoding in each packet sender can change encoding during conference. RTP header also contains sequence numbers, timestamps. 11 June

24 More on RTP RTP does not provide any mechanism to ensure timely data delivery or other QoS guarantees. RTP encapsulation is only seen at end systems (not) by intermediate routers. routers providing best-effort service, making no special effort to ensure that RTP packets arrive at destination in timely matter. Each source (camera, microphone, etc) is assigned its own independent RTP stream of packets 11 June

25 RTP Header Payload Type (7 bits): Indicates type of encoding currently being used. If sender changes encoding in middle of conference, sender informs receiver via payload type field. Payload type 0: PCM mu-law, 64 kbps Payload type 3, GSM, 13 kbps Payload type 7, LPC, 2.4 kbps Payload type 26, Motion JPEG Payload type 31. H.261 Payload type 33, MPEG2 video Sequence Number (16 bits): Increments by one for each RTP packet sent, and may be used to detect packet loss and to restore packet sequence. 11 June

26 RTP Header (2) Timestamp field (32 bytes long): sampling instant of first byte in this RTP data packet for audio, timestamp clock typically increments by one for each sampling period (for example, each 125 usecs for 8 KHz sampling clock) if application generates chunks of 160 encoded samples, then timestamp increases by 160 for each RTP packet when source is active. Timestamp clock continues to increase at constant rate when source is inactive SSRC field (32 bits long): identifies source of the RTP stream. Each stream in RTP session should have distinct SSRC. 11 June

27 Real-Time Control Protocol (RTCP) works in conjunction with RTP. each participant in RTP session periodically transmits RTCP control packets to all other participants. each RTCP packet contains sender and/or receiver reports report statistics useful to application: # packets sent, # packets lost, inter-arrival jitter, etc. feedback can be used to control performance sender may modify its transmissions based on feedback 11 June

28 RTCP - Continued each RTP session: typically a single multicast address; all RTP /RTCP packets belonging to session use multicast address. RTP, RTCP packets distinguished from each other via distinct port numbers. to limit traffic, each participant reduces RTCP traffic as number of conference participants increases 11 June

29 RTCP Packets Receiver report packets: SSRC of RTP stream, fraction of packets lost, last sequence number, average interarrival jitter Sender can adjust encoding rate in response to statistics Sender report packets: SSRC of RTP stream, current time, number of packets sent, number of bytes sent Receivers can synchronize multiple streams (nxt slide) Source description packets: address of sender, sender's name, SSRC of associated RTP stream provide mapping between the SSRC and the user/ host name 11 June

30 Synchronization of Streams RTCP can synchronize different media streams within a RTP session consider videoconferencing app for which each sender generates one RTP stream for video, one for audio. timestamps in RTP packets tied to the video, audio sampling clocks not tied to wall-clock time each RTCP sender-report packet contains (for most recently generated packet in associated RTP stream): timestamp of RTP packet wall-clock time for when packet was created. receivers uses association to synchronize playout of audio, video 11 June

31 RTCP Bandwidth Scaling RTCP attempts to limit its traffic to 5% of session bandwidth. Example Suppose one sender, sending video at 2 Mbps. Then RTCP attempts to limit its traffic to 100 Kbps. RTCP gives 75% of rate to receivers; remaining 25% to sender 75 kbps is equally shared among receivers: with R receivers, each receiver gets to send RTCP traffic at 75/R kbps. sender gets to send RTCP traffic at 25 kbps. participant determines RTCP packet transmission period by calculating avg RTCP packet size (across entire session) and dividing by allocated rate 11 June

32 Real Time Streaming Protocol (RTSP) RTSP (RFC 2326) is a protocol that allows user control over the streaming media rewind, fast forward, pause, resume, repositioning, etc Out-of-band signaling RTSP control messages use different port numbers than media stream: out-of-band port 554 media stream is considered in-band Can use either TCP or UDP 11 June

33 RTSP Example Scenario: metafile communicated to web browser browser launches player player sets up an RTSP control connection, data connection to streaming server 11 June

34 Metafile Example <title>twister</title> <session> <group language=en lipsync> </group> </session> <switch> <track type=audio e="pcmu/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> 11 June

35 RTSP Operation 11 June

36 RTSP Exchange Example C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=play S: RTSP/ OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0- C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: OK 11 June

37 Putting it Together (RTSP+RTP+RTCP) 11 June

38 Adaptive Streaming (recap) Source video file (or live event) is encoded to multiple resolutions and data rates Send the player the first few seconds of video (at default rate or let user choose) As it plays, the video player monitors playback-related indicators such as download time, buffer levels, and CPU utilization to determine if there are connectivity or playback issues For example, if the video buffer ist filling at an adequate rate, or the video data takes too long to download, the viewer may run out of data if the video continues at the current quality level. So the player requests a lower bit-rate stream for the next few seconds of video and continues to monitor playback status 11 June

39 Rate Adaptation Algorithms TCP Friendly Rate Control (TFRC) RTP was designed to work with UDP Hence transmission of audio and video contents could potentially cause congestion collapse of the Internet The idea of TFRC was to follow TCP-like control even when UDP is used for video transmission p=packet loss rate, t RTO = TCP retransmission timeout, s=packet size 11 June

40 TFRC-based Streaming Receiver calculates congestion control indicators and reports back to sender Using Receiver Reports in RTCP Streaming server selects quality of stream that is closest to the calculated rate 11 June

41 HTTP-based Client-controlled Streaming

42 Why HTTP? Scalability and fixed-mobile convergence --- can serve millions of fixed and mobile users, seamlessly Server farms, request redirection, web proxy/cache, Reuse of existing and widely adopted web-based (or HTML or browser-based) content dissemination technology No additional complexity at the server side (existing HTTP servers can be used) --- makes it easy to distribute video Reduces capex and opex HTTP avoids NAT and firewall traversal issues Client intelligence --- provides complete control to the client Client has better knowledge of client-side capability and network condition Personalization can be easier 11 June

43 Apple s HTTP Live Streaming HTTP Live Streaming Overview, developer.apple.com

44 HTTP Live Streaming (HLS) Access audio and video from standard web servers and play on Apple devices iphone, ipad, ipod touch, Apple TV, imac Live broadcast as well as prerecorded content Supports multiple streams of different bitrates for the same content Dynamic stream switching capability for the client to address network bandwidth changes Allows encryption via HTTPS Is an IETF Internet draft (draft-pantos-http-livestreaming-07, Sep 30, 2011) 11 June

45 HLS Clients Browser safari can play within a webpage (ipad and desktops) Media Player launches full screen media player for iphone and ipod touch Built-in client for Apple TV 11 June

46 HLS Architecture Three components Media preparation server Encodes media into MPEG-4 (H.264) then converts it to MPEG-2 transport stream (TS) suitable for transmission over networks (using hardware) Segments MPEG-2 TS into a series of.ts media files and an index file (using software) Distribution web server Stores.ts and index files and sends them to clients over HTTP Existing standard servers can be used (no specialised server module is required) Clients HTTP clients Can be built in the browser, or standalone application 11 June

47 Index Files (Playlists).M3U8 extension Derives from.m3u format used for MP3 playlists Index file can be created by the segmenter, or it can be created separately by an independent entity Index files are frequently overwritten during live broadcasts, hence time-to-live (TTL) values must be tuned appropriately 11 June

48 Simple example of an index file entire stream is segmented into three 10-sec segments #EXTM3U #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:1 #EXTINF:10, #EXTINF:10, #EXTINF:10, #EXT-X-ENDLIST 11 June

49 Client Fetches index file from a specified URL using HTTP Then fetches.ts files one by one sequentially from the list Once sufficient amount of stream downloaded, client plays the reassembled stream to the user Client ends the process when #EXT-X-ENDLIST tag is encountered 11 June

50 Live Broadcast For live broadcasts, there is no #EXT-X-ENDLIST tag Client refreshes index file periodically and adds any new URLs (new.ts files) to the fetch queue 11 June

51 Adaptive Streaming Master index file points to multiple alternate index files, each serving a stream of different quality and bandwidth requirement (audio must be the same in all streams) Client starts by downloading master index file and the Alternate-A, and starts playing from Alternate-A If available bandwidth changes, client can decide to use other index files, Alternate-B, Alternate-C etc. (hence order of other alternates is not relevant) Master index downloaded only once For live broadcast, alternate index files are refreshed periodically 11 June

52 Master index and alternate streams 11 June

53 Initial experience and the case for multiple index trees User may connect via cellular or WiFi Therefore, Alternate-A stream is important Apple s recommendation 150k stream for Alternate-A for cellular 240k or 440k for Alternate-A if user connects via WiFi This means, we need to store multiple stream trees (master index files), each pointing to a different Alternate-A stream 11 June

54 Aspect Ratio in Adaptive Streaming The aspect ratio in all alternate streams must be the same (changing aspect ratio in the middle of a stream impacts viewing quality of experience) However, pixel dimension (resolution) can change dynamically as long as aspect ratio is preserved Example: both 400x300 and 800x600 have an aspect ratio of 4:3 11 June

55 Client Intelligence How client decides when to switch and where to switch? Client uses heuristics to determine switching Currently, these heuristics are based on measured network bandwidth Some researchers have recently investigated more proactive and predictive heuristics (see references) 11 June

56 Embedding master index in HTML5 <html> <head> <title>http Live Streaming Example</title> </head> <body> <video src=" bipbop/bipbopall.m3u8" height="300" width="400" > </video> </body> </html> 11 June

57 Standardizing HTTP-based Streaming

58 Dynamic Adaptive Streaming over HTTP (DASH) --- 3GPP as well as MPEG T. Stockhammer, Dynamic Adaptive Streaming over HTTP Design Principles and Standards 11 June

59 Based on Apple s HLS Some modifications and different terminologies 11 June

60 Client Intelligence D. Jarnikov and T. Ozcelebi, Client Intelligence for Adaptive Streaming Solutions, in International Journal of Signal Processing: Image Communication, Special Issue on IPTV, vol. 26, no. 7, August 2011, pp

61 Challenges in Adaptive Streaming Throughput of the end-to-end channel may vary over time due to several factors: varying cross-traffic Changes in routing paths Last-mile mobile operator scheduling policies Switching between different content sources Consequences: increased delays or data loss lead to decoder buffer underflow or overflow which in turn cause unwanted pauses and loss in QoE Goal: (i) maximize overall quality of the delivered video and (ii) minimize the number of quality fluctuations that causes user-perceived quality deterioration If the time between switching quality levels is less than 1.5 seconds then it is considered annoying for humans Solution: Client-intelligence 11 June

62 Proposed Solution Granularity of operation: chunk-by-chunk Receiver estimates available bandwidth Controller should select quality level of next chunk such that the chunk should be received before its playback deadline Strategy based on Markov Decision Process (MDP) Optimization Criteria (i) minimize the number of deadline misses (ii) minimize the number of quality level changes and (iii) maximize the chosen quality level 11 June

63 Strategy Details Moment at which reception of a chunk is finished is called a milestone Moment when corresponding chunk should be available to decoder is called a deadline If deadline is missed (chunk s milestone is later than deadline) decoder stalls At each milestone, controller calculates relative progress, defined as the fraction of time remaining until the deadline of the milestone Upper bound, p on relative progress, derived from buffer size Minimum relative progress is zero System state relative progress interval, π k and the previously used quality level, denoted by q m 11 June

64 Strategy Details (contd.) Action: choice of quality level for next chunk which results in a state transition State transition depends on (i) the quality of chunk chosen and (ii) time that it would take to transmit a chunk at the chosen quality level Main challenge: time to transmit chunk of quality q is a random variable which depends on Chunk size Available bandwidth For MDP model, the CDF of transmission time of a chunk at quality level q has to be calculated Significant changes in network conditions requires recomputation of strategy 11 June

65 Strategy Details (contd.) Revenue function based on rewards and penalties Reward: related to perceived quality of video, e.g., PSNR, VQM, etc Penalty: related to number of deadline penalties and switching quality levels MDP output is a decision strategy (a look-up table) that maximizes the average revenue per transition, which is fed to the controller Successive approximation solution technique employed for solving MDP 11 June

66 Evaluation Simulation Configurations Video Statistics Network Statistics Fixed Semi-Dynamic Dynamic Off-line Off-line Online Off-line Online Online MDP resolution Off-line Online Online 11 June

67 Semi-dynamic Test Implementation on iphone 3G (ios 4.2) based on Apple s HTTP Live Streaming Video sequences Big Buck Bunny ( and Elephants Dream ( 5 MPEG-2 video quality streams 150kbps, 300kbps, 450kbps, 700kbps, 1000kbps Video and audio (128kbps) multiplexed into separate MPEG-2 TS stream segmented into 4 second chunks Generated traces by storing chunks on a web-server in Ohio, USA and accessing them with a client connected via a wireless ADSL model in Eindhoven, Netherlands 11 June

68 Semi-dynamic Test (contd.) CDF of 4 sec chunks for the 5 qualities Characteristics of network traces used Session 1 (kbps) Session 2 (kbps) Average Throughput Standard Deviation June

69 Semi-dynamic Test: Results Quality is slightly higher for session 1 for smaller history values Riskier strategy employed by controller Penalized by higher deadline misses Overall the impact of length of history is not significant 11 June

70 Semi-dynamic Test: Results Changing quality level by 2 or more is rare Session 1: decreasing trend with longer history Longer history results in a more conservative strategy which in turn results in decreased deadline misses and quality changes History longer than 2-3 minutes has no significant influence 11 June

71 Dynamic Test Similar setup as semi-dynamic test Single stream: Big Buck Bunny Server: laptop running Apache Web server Laptop connected to wireless AP via Ethernet Traffic shaper on laptop-ap link 10 tests Compared with Apple s native streaming solution Video statistics computed on-the-fly Network history limited to 2 minutes MDP solved on reception of each chunk to generate updated strategy 11 June

72 Dynamic Test (Results) Native solution: extremely conservative and underutilizes bandwidth MDP solution: more responsive and achieves better average quality (1.89 vs 1.22) 11 June

73 Streaming Optimization for Fast Moving Users

74 Geo-sensitivity of Network Performance Measurements in Sydney and New York

75 2008 MEASUREMENT IN SYDNEY (3G) 200 meter scale measurements J. Yao, S. Kanhere and M. Hassan, "An Empirical Study of Bandwidth Predictability in Mobile Computing", WiNTECH 08 in conjunction with ACM MOBICOM, September June

76 Measurement Architecture Probe UNSW Downlink Probe (Packet Train) Probe Trigger (every 200m) Internet Bandwidth is measured every 200 meters of a road Provider B (HSDPA) Provider A (HSDPA) Provider C (pre-wimax) Probe Client 11 June

77 Measurement Hardware/Software Off-the-shelf Hardware (Soekris) Totally user-driven (no support from service provider) 11 June

78 Routes Taken Two routes (inbound: 7Km & outbound: 16.5Km) Typical urban driving speed ~70-80Kmh 75 repeated trips spread over 8 months (Aug 07 Apr 08) Collectively 60 driving hours & 1600Km inbound UNSW outbound 11 June

79 Bandwidth Data Set time!!lat!!long bw(a)!!bw(b)!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! Example trace file from one trip: Available for download: 11 June

80 Quantizing the bandwidth signal 11 June

81 Capturing Bandwidth Randomness Compute symbol probabilities in the data (P A P B P C P D P E P F P G ) Yields probability distribution function (PDF) Sort data according to location --- location specific PDF or location PDF If bandwidth is not geo-sensitive, all location will have identical PDF 11 June

82 Does location affect bandwidth? Per-location bandwidth distribution (assuming 500m location granularity) They can be very different! Bandwidth is geo-sensitive! 11 June

83 Quantify differences in bandwidth distributions between adjacent road segments (L 1 distance analysis: values in 0-2) Mobile apps could be in for a bumpy ride! 11 June

84 An Entropy-based Approach for Verifying Geo- Sensitivity of Network Bandwidth Compute entropy for the entire data without using the location information (collated entropy) Sort data according to location, then compute entropy for each location, take the average for all entropies (location entropy) Bandwidth is geo-sensitive if location entropy < collated entropy 11 June

85 Entropy Calculation Collated entropy When X is a completely random process Location entropy (for location j) n H(X l j ) = p(x i l j )log 2 p(x i l j ) i=1 Lower the entropy, lower the uncertainty, better the predictability Entropy=0 à completely deterministic Entropy=log 2 X à completely random Example of a random variable with 2 possible outcomes, 0,1. 11 June

86 Entropy Results for Sydney (1) (location entropy < collated entropy in general) Bandwidth at some locations is harder to predict than others 11 June

87 Entropy Results for Sydney (2) Average Location Entropy 11 June

88 2010 MEASUREMENT IN NEW YORK (3G & WIFI) (10 meter scale measurements) Deshpande, Hou, and Das, Performance Comparison of 3G and Metro-Scale WiFi for Vehicular Network Access, ACM International Measurement Conference, November 1-3, June

89 Measurement Setup Repeated drive over a 9- mile route in Long Island, New York (see right) Cellular (EVDO) + Metroscale WiFi Measure bandwidth distribution at 10-30m Compute bandwidth entropy Long Island, New York 11 June

90 Results (H stands for entropy) Finding location entropy is lower than their respective total entropies 11 June

91 Implications of bandwidth geo-sensitivity for mobile streaming Current HTTP client intelligence is based on network monitoring during the trip ( location-based history not used) For geo-sensitive bandwidth, access to location-based history (geointelligence) would be an advantage Let us have a detailed look at the Sydney data 11 June

92 Bandwidth Varies Significantly at Many Geographical Scales (individual trip data for 3 trips - inbound) Data for Provider C (pre-wimax) 11 June

93 Bandwidth Varies Significantly at Many Geographical Scales (average bandwidth from 75 trips) 3G bandwidth exhibits significant geo-sensitivity even at 500m scale 11 June

94 How Geointelligence Can Help (assume it stores average bandwidth observed in a given location from the previous trips) Avg(114,153) = 133 At the entry to location #7, geointelligence would give 133 kbps, but a link monitor agent would give 544 Convergence to 68 would be faster and smoother if started from 133 instead of June

95 Root Mean Square Error Comparison (averaged over all 75 trips) Error with link monitor (no geointelligence) Error with geointelligence RMSE(Kbps) A B C Providers 11 June

96 Existing Adaptive Video Streaming Store several streams of different quality (PSNR) for the same video Current bandwidth is continuously monitored Switch streams (quality or PSNR) according to current bandwidth Adaptation algorithms TFRC, 3GPP PSS, HTTP, proprietary, 11 June

97 Adaptive Video Streaming with Geointelligence Geointelligent Server (maps bandwidth to location) Streaming Clients Either the client or the server communicates with a geointelligent server 11 June

98 Application of Geointelligence to Mobile Streaming J. Yao, S. Kanhere, and M. Hassan, Improving QoS in High-speed Mobility using Bandwidth Maps", IEEE Transactions on Mobile Computing, 11(4), April 2012, pp Curcio, Vadakital and Hannuksela, Geo-predictive real-time media delivery in mobile environment", ACM MOVID 10 in conjunction with ACM Multimedia 2010 Evensen et al Mobile Video streaming using location-based network prediction and transparent handover NOSSDAV 2011 Riiser et al., Video streaming using a location-based bandwidth-lookup service for bitrate planning in press, ACM Transactions on Multimedia Computing, Communications and Applications. 11 June

99 Applying Geointelligence to TFRC J. Yao, S. Kanhere, and M. Hassan, Improving QoS in High-speed Mobility using Bandwidth Maps", IEEE Transactions on Mobile Computing, 11(4), April 2012, pp June

100 TFRC TCP Friendly Rate Control A widely discussed algorithm for UDP-based adaptive multimedia TCP-like AIMD (additive increase multiplicative decrease) congestion control Slow ramp up for sudden low to high bandwidth (wastes high PSNR opportunities) Packet loss for sudden high to low bandwidth (quality may degrade beyond acceptable level) 11 June

101 Geo-TFRC (TFRC with access to geointelligence) Goal: To help TFRC adapt to sudden bandwidth variations at location crossings 11 June

102 TFRC and Geo-TFRC Simulation geointelligence Foreman.qcif self-concatenated to create a 30 min video lasting the entire trip 11 June

103 Video Rate Adaptation Evaluation in ns-2 Based on Evalvid-RA (Lei et al. 07), Evalvid (Ke et al. 08) 11 June

104 Video quality measurement (video quality is affected by packet loss from buffer overflow at cellular tower) The PSNR metric For acceptable video quality: PSNR >= 31 (viewing is disrupted for low PSNR) 11 June

105 PSNR Comparison (cont.) Geo-TFRC TFRC 11 June

106 Fraction of Time With Poor Streaming Quality (PSNR < 31) 50% more disruptions 500% more disruptions 11 June

107 Applying Geointelligence to 3GPP Packet-Switched Streaming Service Curcio, Vadakital and Hannuksela, Geo-predictive real-time media delivery in mobile environment", ACM MOVID 10 in conjunction with ACM Multimedia June

108 Simulation Architecture Synthetic bandwidth trace following a 2- state Markov chain With geointelligence, client predicts bad condition well ahead and communicates with server Server pushes enough data quickly to client to overcome buffer underflow at bad locations 11 June

109 Results NOR: No-Rate Adaptation RAT: Rate Adaptation Transmission (purely reactive) GPT: Geo-predictive Rate Adaptation Transmission 11 June

110 Real Experiments with Geointelligent Streaming Evensen et al Mobile Video streaming using location-based network prediction and transparent handover NOSSDAV 2011 Riiser et al., Video streaming using a location-based bandwidthlookup service for bitrate planning in press, ACM Transactions on Multimedia Computing, Communications and Applications.

111 Geo-intelligent Streaming Architecture Bandwidth maps of a single 3G operator were collected for 4 public transport routes in Oslo Bus Train (metro) Ferry Tram 11 June

112 Example: Bus 11 June

113 Results Ferry Bus 11 June

114 Results (2) Ferry Bus 11 June

115 Content Distribution to Fast Moving Users

116 The Case of 3G A. KYRIAKIDOU, N. KARELOS, A. DELIS, VIDEO STREAMING FOR FAST MOVING USERS IN 3G MOBILE NETWORKS MOBIDE, 12 JUNE 2005, BALTOMORE, MARYLAND, USA 11 June

117 Video Distribution Challenge for Fast Moving Users Media-server to BS delay could be reduced by pushing the entire clip to the BS, but Fast moving users have a very short cell residence About 50 seconds for a 0.7km cell radius at 100km/hour A typical video clip will have to be delivered over different BSs Taken from Kyriakidou et al. MobiDE June

118 Cell-residence time based video segmentation Media server segments a video clip into variable sizes Send each segment to different BSs along the route of the mobile user segment _ size = distance speed 11 June

119 Reducing network cost with media server coordination Network cost can be reduced by coordinating between media servers Each server looks after a group of cells closest to it Multiple media server becomes involved in delivering the video clip to the same user 11 June

120 The Case of WiFi U. SHEVADE, Y-C CHEN, L. QIU, Y. ZHANG, V. CHANDAR, M. K. HAN, H. H. SONG, Y. SEUNG, Enabling High-Bandwidth Vehicular Content Distributio, ACM CONEXT June

121 WiFi Features Much cheaper than 3G 81% smartphone users prefer wifi over 3G (for data) Problem: vehicle-ap contact time is too short to download the entire video clip 70% connection opportunities are less than 10 sec 11 June

122 With AP, wireless could be faster than wireline! DSL throughput ranges between 768Kbps 6Mbps Recent vehicle-ap test results 39.7Mbps with n on 2.4 GHZ 56.1Mbps with n on 5GHz Storing media at the AP before the vehicle arrives can solve the short contact time problem At 56Mbps, 70 MB video can be downloaded in 10 seconds (most video clips are less than 70 MB) Media server DSL (768Kbps-6Mbps) 56Mbps 11 June

123 Vehicular Content Distribution (VCD) with Standalone APs Deploy standalone (no Internet connection) APs at petrol stations, MacDonalds etc. Cheap to deploy and cheap to configure with lots of storage APs are allowed to fetch (highly sought after) videos from a passing vehicle (at a very high speed, e.g. 56 Mbps) 11 June

124 On the storage requirements of AP/BS For high-speed mobility, it s best if the video content is available at the AP/BS YouTube has around 143 distinct million videos, but The popularity has a power law distribution --- a small percentage is watched most often, while most of the videos are accessed only occasionally Storing only 20% of videos at the AP/BS will reduce 80% traffic between AP/BS and the Internet à 272 TB per AP/BS N. Amran et al., QoE-based Transport Optimization for Video Delivery over Next Generation Cellular Networks 16th IEEE Symposium on Computers and Communications, ISCC 2011, Kerkyra, Corfu, Greece, June 28 - July 1, June

125 Conclusions (1) The first challenge is about the latency from Internet server to AP/BS This latency could be reduced by caching contents at AP/BS Falling storage costs combined with HTTP-based streaming makes caching large amount of contents at AP/BS feasible Storing only 20% of all YouTube videos at the AP/BS will reduce 80% traffic between media server and AP/BS (requires only 272 TB per AP/BS) 11 June

126 Conclusions (2) The 2 nd challenge is how to best adapt the content under variable bandwidth Mobile bandwidth appears to be highly geo-sensitive Geointelligence is a promising tool for content adaptation in mobile networks How to engineer geointelligence at a large scale and how to best integrate geointelligence with content applications are interesting problems to solve 11 June

127 References (1) HTTP Live Streaming Overview, developer.apple.com T. Stockhammer, Dynamic Adaptive Streaming over HTTP Design Principles and Standards D. Jarnikov and T. Ozcelebi, Client Intelligence for Adaptive Streaming Solutions, in International Journal of Signal Processing: Image Communication, Special Issue on IPTV, vol. 26, no. 7, August 2011, pp A. Kyriakidou, N. Karelos, A. Delis, Video Streaming for Fast Moving Users in 3G Mobile Networks, in Proceedings of MOBIDE 2005 U. Shevade, Y-C Chen, L. Qiu, Y. Zhang, V. Chandar, M. K. Han, H. H. Song, Y. Seung, Enabling High-Bandwidth Vehicular Content Distributio in Proceedings of ACM CONEXT 2010 N. Amran et al., QoE-based Transport Optimization for Video Delivery over Next Generation Cellular Networks in Proceedings of 16th IEEE Symposium on Computers and Communications, ISCC June

128 References (2) J. Yao, S. Kanhere and M. Hassan, "An Empirical Study of Bandwidth Predictability in Mobile Computing", in Proceedings of WiNTECH 08 (in ACM MOBICOM 2008). J. Yao, S. Kanhere, and M. Hassan, Improving QoS in High-speed Mobility using Bandwidth Maps", IEEE Transactions on Mobile Computing, 11(4), April 2012, pp Deshpande, Hou, and Das, Performance Comparison of 3G and Metro-Scale WiFi for Vehicular Network Access, ACM International Measurement Conference, November 1-3, Curcio, Vadakital and Hannuksela, Geo-predictive real-time media delivery in mobile environment", in Proceedings of ACM MOVID 10 (in conjunction with ACM Multimedia 2010) Evensen et al Mobile Video streaming using location-based network prediction and transparent handover NOSSDAV 2011 Riiser et al., Video streaming using a location-based bandwidth-lookup service for bitrate planning in press, ACM Transactions on Multimedia Computing, Communications and Applications. 11 June

129 THANKS FOR YOUR ATTENTION 11 June