470 likes | 588 Views
MPEG Streaming over Mobile Internet. Kyunghee Lee and Myungchul Kim {leekhe, mckim}@icu.ac.kr. Contents. Introduction Related Work Proposed Mechanism System Design Testbed Configuration Experiments Performance Evaluation Conclusions References. Introduction.
E N D
MPEG Streaming over Mobile Internet Kyunghee Lee and Myungchul Kim {leekhe, mckim}@icu.ac.kr
Contents • Introduction • Related Work • Proposed Mechanism • System Design • Testbed Configuration • Experiments • Performance Evaluation • Conclusions • References
Introduction • General multimedia data characteristics • Intolerant to delay and jitter variance • Error-sensitive • Characteristics of mobile Internet • Frequent routing path changes due to handoffs • Higher error rate in wireless link • Effects on streaming multimedia data in mobile Internet • Handoff delay • Re-routing toward congested network delay increment • Higher packet loss probability due to mobility Significant quality degradation of streaming multimedia data
Introduction (cont’d) • Popular Quality of Service (QoS) guarantee mechanisms • Differentiated Service (DiffServ) [2] • Guarantees aggregated QoS for multiple flows • Can not guarantee specific QoS requirement for each data flow • Integrated Service (IntServ) • Network resource reservation for specific data flow • Strict guarantees for multimedia streams with various QoS requirements • Resource Reservation Protocol (RSVP) [3]
Introduction (cont’d) • Problems of RSVP in Mobile Internet • Mobile Host (MH) handoff invalidates existing reservation paths overhead and delay to re-establish new RSVP session • Movement to congested wireless cell fail to get admission to re-establish new RSVP session • Seamless QoS guarantees are impossible • Existing approaches • Mobile RSVP (MRSVP) [15] • Hierarchical Mobile RSVP (HMRSVP) [16] • A method of Concatenation and Optimization of Reservation Path (CORP) [10]
Related Work • Priority-based scheduling for MPEG streaming on Mobile Internet • Differentiated delivery service depending on the importance of each MPEG frame data Priority-aware MPEG Server CH I P B B R1 I congested FA P B B P Packet drop : MPEG video stream I : Non-multimedia Traffic MPEG Client MH
Related Work (cont’d) • Classify IP packets into two classes depending on its payload • Class 1: containing MPEG and GOP header (priority 1) • Class 2: containing MPEG I frame (priority 1) • Class 3: containing MPEG B, P frame (priority 7, best-effort) • Uses TOS field in IP packet header as a classifier 4 TOS bits minimize monetary cost minimize delay maximize throughput maximize reliability 1-bit unused 3-bit precedence field (currently ignored) 0 16 31 4-bit version 4-bit header len. 8-bit TOS field 16-bit total length (in bytes) 3-bit flag 13-bit fragment offset 16-bit identification 8-bit time-to-live (TTL) 8-bit protocol 16-bit header checksum 32-bit source IP address
Related Work (cont’d) • Priority-aware MPEG streaming server
Related Work (cont’d) • Mobile IP Foreign Agent (FA) • Is the most probable spot of packet loss due to the network congestion • Acts as a gateway router for its own wireless subnet • Runs mobile IP FA daemon program • Performs priority-based CBQ scheduling for the traffic delivered toward MH • Mobile MPEG client • Plays MPEG video stream from the server • Advantages • Simple and light-weight mechanism suitable for wireless/mobile networking environment • Significant video quality improvement can be achieved though the extra bandwidth is scarcely consumed
Related Work (cont’d) • Experiment scenario • Sample MPEG file specification • Background traffic pattern * Total 1516 frames • Testbed configuration Non-diffserv router R MPEG video stream Background traffic Priority-aware MPEG server FA HA Priority-based scheduling on/off Wireless subnet 1 Wireless subnet 2 MH ** The bandwidth limit in the WaveLAN II wireless link: 5.07 Mbps
Related Work (cont’d) • Experimental results • Number of the received packets (at client) containing either MPEG header or I-frame (Class 1, 2) • Each packet size: 1024 bytes • Total number of Class 1 or 2 packets: 151 • Number of the received packets: 151 (the proposed mechanism), 121 (FIFO scheduling) • Transfer rate variation of the MPEG video stream • Transfer rate is more independent on the amount of the background traffic ( ) Class 1, 2 packets are served by the priority-based scheduling
Related Work (cont’d) • Experimental results (cont’d) • PSNR value distribution • Amount of the received traffic: 824 Kbytes (FIFO), 852 Kbytes (CBQ) out of total 1.2 Mbytes • Number of frames 20 dB: 919 (FIFO), 775 (CBQ) • Number of frames with 78 dB: 151 (FIFO), 192 (CBQ) • 78 dB: same quality with the original image • 20 dB: impossible to be recognized by human eyes Out of total 1440
Related Work (cont’d) • CORP • Base Station (BS) takes charge of making and managing RSVP sessions on behalf of MH • Consists of two main processes • Concatenation of Reservation Path (CRP) process • Reservation path extension technique • Current BS pre-establishes pseudo reservation path (PRP) toward its neighboring BSs to prepare for MH’s handoff • When MH handoffs, corresponding PRP is activated to guarantee QoS for MH • Optimization for Reservation Path (ORP) process • Solves infinitely long path extension problem and reservation path loop problem of CRP process • Optimizes the extended reservation path
MH requests a new RSVP session and BS_B makes it on behalf of the MH CRP inform • BS_B sends CRP inform messages to its neighbors CRP inform BS_C BS_B BS_A Related Work (cont’d) • CRP Process PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • CRP Process • MH requests a new RSVP session and BS_B makes it on behalf of the MH • BS_B sends CRP inform messages to its neighbors • BS_B makes PRP to its neighbors PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • CRP Process • MH requests a new RSVP session and BS_B makes it on behalf of the MH • BS_B sends CRP inform messages to its neighbors • BS_B makes PRP to its neighbors • MH handoffs toward BS_C’s cell PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • CRP Process • MH requests a new RSVP session and BS_B makes it on behalf of the MH • BS_B sends CRP inform messages to its neighbors • BS_B makes PRP to its neighbors CRP activate • MH handoffs toward BS_C’s cell • BS_C sends CRP activate message to the previous BS (BS_B) PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • CRP Process • MH requests a new RSVP session and BS_B makes it on behalf of the MH • BS_B sends CRP inform messages to its neighbors • BS_B makes PRP to its neighbors • MH handoffs toward BS_C’s cell • BS_C sends CRP activate message to the previous BS (BS_B) • BS_B forwards MPEG-1 video through the activated PRP PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • CRP Process • MH requests a new RSVP session and BS_B makes it on behalf of the MH • BS_B sends CRP inform messages to its neighbors • BS_B makes PRP to its neighbors • MH handoffs toward BS_C’s cell • BS_C sends CRP activate message to the previous BS (BS_B) • BS_B forwards MPEG-1 video through the activated PRP • BS_B terminates useless PRP toward BS_A PRP CORP message RSVP session Activated PRP
BS_C sends IGMP group report message to its gateway router IGMP report BS_C BS_B BS_A Related Work (cont’d) • ORP Process PRP CORP message RSVP session Activated PRP
BS_C sends CRP release message to the previous BS (BS_B) CRP release BS_C BS_B BS_A Related Work(cont’d) • ORP Process • BS_C sends IGMP group report message to its gateway router • BS_C joins into the existing multicast RSVP session PRP CORP message RSVP session Activated PRP
BS_C BS_B BS_A Related Work (cont’d) • ORP Process • BS_C sends IGMP group report message to its gateway router • BS_C joins into the existing multicast RSVP session • BS_C sends CRP release message to the previous BS (BS_B) • BS_B terminates the activated PRP and BS_C uses the newly optimized one to deliver MPEG data stream to MH PRP CORP message RSVP session Activated PRP
CRP inform CRP inform BS_C BS_B BS_A • BS_C sends CRP inform messages to its neighbors to prepare MH’s probable movement Related Work (cont’d) • ORP Process • BS_C sends IGMP group report message to its gateway router • BS_C joins into the existing multicast RSVP session • BS_C sends CRP release message to the previous BS (BS_B) • BS_B terminates the activated PRP and BS_C uses the newly optimized one to deliver MPEG data stream to MH • BS_B leaves the multicast RSVP session PRP CORP message RSVP session Activated PRP
Implementation of CORP • The testbed architecture
Implementation of CORP OS: FreeBSD 2.2.2 Wireless LAN: WaveLAN I (Lucent Tech.) Mobile IP: MIP– July 97 (Portland State Univ.) RSVP: Release 4.2a4 (Univ. of Southern California) Traffic Control: Alternate Queueing Pack. ver 1.1.3 (SONY) Main Idea: CORP( ICU) Application: Video & Audio Phone by VIC & VAT • The experimental testbed environment
Implementation of CORP (cont’d) • Experimental testbed • Consists of a RSVP router, two BSs support CORP function, and a MH • Each BS has two network interfaces: an Ethernet card and a WaveLAN I ISA card • Each BS, router and MH runs FreeBSD 2.2.2 • WaveLAN driver on FreeBSD is installed at BSs and the MH • Mobile IP ver. July97 from Portland State Univ. supports mobility • RSVP rel4.2a4 from Southern California Univ. has been modified to implement • CORP mechanism • Alternate Queueing Package (ALTQ) ver. 1.1.3 is install for traffic control • Current implementation of the proposed method • CRP module: reservation path extension • ORP module: extended reservation path optimization using a newly established • RSVP session
Experimental Results • Elapsed delays for resuming data transfer after a handoff • - Each result is calculated as a mean value of delays measured 20 times in the testbed • Where a MH is a receiver of traffics and a sender is 2 hops away from the MH
Experimental Results (cont’d) • Transfer rate variation during CRP processing time • (with no background traffic) CRP completion time (125 ms) • - 50 kilobytes of bandwidth has been reserved • A sender transmits 500 data packets per second with a fixed size of 100 bytes • Each value was measured by an amount of data received by a MH every 0.1 seconds
Experimental Results (cont’d) • Transfer rate variation during CRP processing time • (with full background traffic) CRP completion time (125 ms) • - FTP application generates background traffics • Total available bandwidth of the testbed is estimated at about 150 kbytes/sec
Experimental Results (cont’d) • CRP Delay with the distance between MH and CH • - A delay for establishment of a new RSVP session is estimated as : • RTT of RSVP path message + router’s processing time of RSVP resv message • CRP completion time is not much dependant on the distance between a MH and a CH • but the distance between two neighbor BSs
Experimental Results (cont’d) • CRP Packet loss with the distance between MH and CH • - 50 kilobytes of bandwidth has been reserved • A sender transmits 500 data packets per second with a fixed size of 100 bytes • CRP provides better performance as the distance becomes longer
Experimental Results (cont’d) • ORP processing time • - Each result is calculated as a mean value of delays measured 20 times in the testbed • Where a MH is a receiver of traffics and a sender is 2 hops away from the MH
Experimental Results (cont’d) • Transfer rate variation during ORP processing time ORP delay • - 30 kilobytes of bandwidth has been reserved • A sender transmits 300 data packets per second with a fixed size of 100 bytes • Each value was measured by an amount of data received by a MH every 10 milliseconds
Experimental Results (cont’d) • ORP delays according to distance between MH and CH • - This result backs up that ORP has a good scalability • ORP delay is estimated as approximately 18 ms, where the distance is 15 hops
Proposed Mechanism • Motivation • To provide QoS guarantees for MPEG video streaming services with mobility support • Proposed System • Uses CORP to guarantee seamless QoS in mobile networks • Provides MPEG-1 video streaming services over CORP • CORP-aware video streaming server and client • CORP-capable mobile agents (Base Stations)
System Design CORP message MPEG-1 data • Video Server Architecture • CORP adaptation module handles CORP messages and takes charge of resource reservation process • MPEG-1 traffic transfer module transfers MPEG-1 stream to BS at the speed of a reserved bandwidth
System Design (cont’d) • Base Station Architecture • CORP message handler module handles CORP messages which are generated by neighboring BSs or a mobile client • traffic forward module receives MPEG-1 streaming data from the video server and forwards it to a neighboring BS or directly delivers it to the client
System Design (cont’d) • Client Architecture • CORP adaptation module handles CORP messages • Handoff detection module detects a handoff and determines when MH has to request the activation of PRP • MPEG-1 traffic receiver modulereceives MPEG-1 streaming data from a current BS • MPEG-1 video playback moduleplays the MPEG-1 video from the received stream
Video Server BS1 BS2 Client Service Request Service Request Service Request Ack Service Request Ack RSVP path RSVP resv PRP establishment MPEG-1 traffic MPEG-1 traffic Client Handoffs (BS1BS2) System Design (cont’d) • MPEG-1 Service Procedure over CORP before Handoff
Video Server BS1 BS2 Client Client handoffs CRP Activate Request CRP Activate CRP Activate Ack MPEG-1 traffic MPEG-1 traffic MPEG-1 traffic ORP Request ORP Request Ack RSVP path RSVP resv MPEG-1 traffic MPEG-1 traffic System Design (cont’d) • MPEG-1 Service Procedure over CORP after Handoff (BS1BS2)
Home Agent Video Server Wired Subnet_1 Wired Subnet_2 Gateway BS1 BS2 MH Wireless Subnet_1 Wireless Subnet_2 Testbed Configuration • Wired subnet bandwidth • 10 Mbps Ethernet • Wireless subnet bandwidth • IEEE 802.11b wireless LAN with the bandwidth of 11 Mbps • BS • Runs FA daemon of Mobile IP • Runs CORP daemon • Client • Runs MH daemon of Mobile IP • Runs VOD client program • Video Server • Supports CORP-aware MPEG-1 streaming service • Network Architecture
Experiments • Sample Video Clip Specification • Experiment Scenarios • Background traffic generation: MGEN • Maximum throughput of wired network: 9.34 Mbps • Wired subnet_1: non-congested • Wired subnet_2: congested • 8.2 Mbps background traffic • Movement of MH: BS1 BS2 • Experiment Cases • MPEG-1 streaming with CORP and TCP • MPEG-1 streaming with TCP only • MPEG-1 streaming with CORP and UDP • MPEG-1 streaming with UDP only
Performance Evaluation I. MPEG-1 Streaming with CORP and TCP II. MPEG-1 Streaming with TCP only • QoS Guarantee • Data rate is measured at client per each second while the sample MPEG file is being delivered • Not much difference in data rate distribution between before and after handoff cases in (I) • Amount of packet loss due to handoff is about 81Kbytes in (I) • 84 percents are less than 0.3 Mbps after handoff in(II) * 150KBps bandwidth reserved
Performance Evaluation (cont’d) I. MPEG-1 Streaming with CORP and UDP II. MPEG-1 Streaming with UDP only • QoS Guarantee (cont’d) • Not much difference in data rate distribution between before and after handoff cases in (I) • Average data rate before handoff is significantly higher than that after handoff in (II) • Average packet loss rate is about 0.6 Mbps in (II) * 200KBps bandwidth reserved
Performance Evaluation (cont’d) I. MPEG-1 Streaming with CORP and TCP II. MPEG-1 Streaming with TCP only • Quality of Streaming Video • If Peak Signal to Noise Ratio (PSNR) is less than 20 dB, the frame can be regarded as being lost • In (I), MPEG-1 streaming data did not suffer from loss or delay under the congested situation • 11 frames were lost during CRP process time in (I) • the total number of received frames is only 1107 frames out of 2000 frames for 80 seconds in (II)
Performance Evaluation (cont’d) • Quality of Streaming Video (cont’d) • The average PSNR is 69.6 dB before MH’s handoff and 68.6 dB after MH’s handoff in (I) • MH could not play back MPEG-1 video stream correctly after handoff in (II) because of too high packet loss rate (0.6 Mbps) I. MPEG-1 Streaming with CORP and UDP II. MPEG-1 Streaming with UDP only
Conclusions • QoS guarantee for MPEG-1 streaming service in Mobile Internet • QoS guarantee mechanism with mobility support –CORP • Implementation of MPEG-1 streaming service over CORP • Streaming Video Quality Improvement • Significantly better PSNR values in both cases of using TCP and UDP when CORP mechanism is applied • MPEG-1 streaming with CORP and TCP provided the highest video quality in the experiments • Future work • Reduction in the packet loss during a handoff with CORP • Reduction in the packet loss over wireless links when UDP is used as a transport protocol