1 nv-2003 mpeg streaming over mobile internet kyunghee lee and myungchul kim {leekhe,
DESCRIPTION
3 NV-2003 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 dataTRANSCRIPT
1 NV-2003
MPEG Streaming over Mobile Internet
Kyunghee Lee and Myungchul Kim{leekhe, mckim}@icu.ac.kr
2 NV-2003
Contents• Introduction
• Related Work
• Proposed Mechanism
• System Design
• Testbed Configuration
• Experiments
• Performance Evaluation
• Conclusions
• References
3 NV-2003
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
4 NV-2003
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]
5 NV-2003
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 sessionSeamless 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]
6 NV-2003
Related Work• Priority-based scheduling for MPEG streaming on
Mobile Internet– Differentiated delivery service depending on the
importance of each MPEG frame data
R1
FA
CH
IB
B
PI
BP B
I
P
Priority-awarePriority-awareMPEG ServerMPEG Server
MHMH
: : MPEG video streamMPEG video stream
: : Non-multimedia TrafficNon-multimedia Traffic
Packet dropPacket drop
MPEG ClientMPEG Client
congestedcongested
7 NV-2003
• 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-bitversion
4-bitheader len. 8-bit TOS field 16-bit total length (in bytes)
16-bit identification 3-bit flag 13-bit fragment offset
8-bit time-to-live (TTL) 8-bit protocol 16-bit header checksum
32-bit source IP address
00 1616 3131
3-bit precedence field(currently ignored)
minimizedelay
maximizethroughput
maximizereliability
minimizemonetary
cost
1-bitunused
4 TOS bits
Related Work
8 NV-2003
Related Work (cont’d)
• Priority-aware MPEG streaming server
MPEGvideo file
Analysis Packetization
Priority setting
MPEGvideo client
UDP
Priority-aware MPEG video stream server
Parse theMPEG file
make an offsettable
move MPEG datafrom a file to the buffer
check up the data inthe buffer set the TOS
value of thepacket
decide the value ofTOS field
9 NV-2003
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
10 NV-2003
Related Work (cont’d)
• Testbed configuration
Non-diffserv routerNon-diffserv routerR
HA FA
MH
BackgroundBackgroundtraffictraffic
Priority-awarePriority-awareMPEG serverMPEG server
MPEG video streamMPEG video stream
Priority-based scheduling on/offPriority-based scheduling on/off
WirelessWirelesssubnet 1subnet 1
WirelessWirelesssubnet 2subnet 2
Experiment scenarioSample MPEG file specification
Background traffic pattern
File size 1.2 MbytesPlaying out
Duration 48 sec
Frame rate 30 fps
Avg. bit rate
214 Kbps
ContainingFrames 102 I, 404 P, 1010 B
* * Total Total 1516 frames 1516 frames
****The bandwidth limit in the WaveLAN II The bandwidth limit in the WaveLAN II wireless link: wireless link: 5.07 Mbps5.07 Mbps
11 NV-2003
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
80000
100000
120000
140000
160000
180000
200000
1 5 9 13 17 21 25 29 33 37 41 45 (sec)
(bps
)
FIFO scheduling priority-based CBQ scheduling
12 NV-2003
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
050
100
150200250300
350400450
10 20 30 40 50 60 70 78PSNR (dB)
Num
ber
of fr
ames
FIFO scheduling Priority-based CBQ scheduling
Out of total1440
13 NV-2003
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
14 NV-2003
Related Work (cont’d)
• CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
CRP inform
CRP inform
CORP message
RSVP session
PRP
Activated PRP
15 NV-2003
Related Work (cont’d)
• CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
III. BS_B makes PRP to its neighbors
CORP message
RSVP session
PRP
Activated PRP
16 NV-2003
Related Work (cont’d)
• CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
III. BS_B makes PRP to its neighbors
IV. MH handoffs toward BS_C’s cell
CORP message
RSVP session
PRP
Activated PRP
17 NV-2003
Related Work (cont’d)
• CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
III. BS_B makes PRP to its neighborsIV. MH handoffs toward BS_C’s cell
CRPactivate
V. BS_C sends CRP activate message to the previous BS (BS_B)
CORP message
RSVP session
PRP
Activated PRP
18 NV-2003
Related Work (cont’d)
CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
III. BS_B makes PRP to its neighborsIV. MH handoffs toward BS_C’s cellV. BS_C sends CRP activate message to the
previous BS (BS_B)VI. BS_B forwards MPEG-1 video through
the activated PRP
CORP message
RSVP session
PRP
Activated PRP
19 NV-2003
Related Work (cont’d)
CRP Process
BS_CBS_BBS_A
I. MH requests a new RSVP session and BS_B makes it on behalf of the MH
II. BS_B sends CRP inform messages to its neighbors
III. BS_B makes PRP to its neighborsIV. MH handoffs toward BS_C’s cellV. BS_C sends CRP activate message to the
previous BS (BS_B)VI. BS_B forwards MPEG-1 video through
the activated PRPVII. BS_B terminates useless PRP toward
BS_A
CORP message
RSVP session
PRP
Activated PRP
20 NV-2003
Related Work (cont’d)
• ORP Process
BS_CBS_BBS_A
CORP message
RSVP session
PRP
Activated PRP
I. BS_C sends IGMP group report message to its gateway router
IGMPreport
21 NV-2003
Related Work (cont’d)
ORP Process
BS_CBS_BBS_A
CORP message
RSVP session
PRP
Activated PRP
I. BS_C sends IGMP group report message to its gateway router
II. BS_C joins into the existing multicast RSVP session
CRPrelease
III. BS_C sends CRP release message to the previous BS (BS_B)
22 NV-2003
Related Work (cont’d)
ORP Process
BS_CBS_BBS_A
CORP message
RSVP session
PRP
Activated PRP
I. BS_C sends IGMP group report message to its gateway router
II. BS_C joins into the existing multicast RSVP session
III. BS_C sends CRP release message to the previous BS (BS_B)
IV. BS_B terminates the activated PRP and BS_C uses the newly optimized one to deliver MPEG data stream to MH
23 NV-2003
Related Work (cont’d)
ORP Process
BS_CBS_BBS_A
CORP message
RSVP session
PRP
Activated PRP
I. BS_C sends IGMP group report message to its gateway router
II. BS_C joins into the existing multicast RSVP session
III. BS_C sends CRP release message to the previous BS (BS_B)
IV. BS_B terminates the activated PRP and BS_C uses the newly optimized one to deliver MPEG data stream to MH
V. BS_B leaves the multicast RSVP sessionCRPinform
CRPinform
VI. BS_C sends CRP inform messages to its neighbors to prepare MH’s probable movement
24 NV-2003
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)
25 NV-2003
System Design
• 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
Video Server
RSVP
TCP/UDP
IP
Wired Link
CORP AdaptationModule
MPEG-1 TrafficTransfer Module
CORP messageMPEG-1 data
26 NV-2003
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
CORP
RSVP
TCP/UDP
IP/Mobile IP
Wired/Wireless Link
CORP MessageHandler Module
TrafficForward Module
27 NV-2003
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 module receives MPEG-1 streaming data from a current BS
– MPEG-1 video playback module plays the MPEG-1 video from the received stream
Client
TCP/UDP
Mobile IP
Wireless Link
CORP AdaptationModule
MPEG-1 TrafficReceiver Module
Handoff DetectionModule
MPEG-1 VideoPlayback Module
28 NV-2003
System Design (cont’d)
• MPEG-1 Service Procedure over CORP before Handoff
Video Server
BS1 ClientBS2
Service Request
Service Request Ack
Service Request
Service Request Ack
RSVP path
RSVP resv
MPEG-1 trafficMPEG-1 traffic
PRP establishment
ClientHandoffs
(BS1BS2)
29 NV-2003
System Design (cont’d)
• MPEG-1 Service Procedure over CORP after Handoff
Video Server
BS1 ClientBS2Client
handoffs
CRP Activate Request
CRP Activate
CRP Activate AckMPEG-1 traffic MPEG-1 traffic MPEG-1 traffic
ORP Request
ORP Request Ack
RSVP path
RSVP resv
MPEG-1 trafficMPEG-1 traffic
(BS1BS2)
30 NV-2003
Testbed Configuration• Network Architecture
Wired subnet bandwidth10 Mbps Ethernet
Wireless subnet bandwidthIEEE 802.11b wireless LAN with the bandwidth of 11 Mbps
BSRuns FA daemon of Mobile IPRuns CORP daemon
ClientRuns MH daemon of Mobile IPRuns VOD client program
Video ServerSupports CORP-aware MPEG-1 streaming service
MH
BS2
Gateway
BS1
Video Server
Wireless Subnet_1
Wireless Subnet_2
Wired Subnet_1 Wired Subnet_2
Home Agent
31 NV-2003
Experiments• 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 CasesI. MPEG-1 streaming with CORP and TCPII. MPEG-1 streaming with TCP onlyIII. MPEG-1 streaming with CORP and UDPIV. MPEG-1 streaming with UDP only
Shrek
Resolution 352 X 288
Average Data Rate (Mbps) 1.39
Frame Rate (fps) 25
Play out duration (sec) 80
Total number of frames 2,000
Sample Video Clip Specification
32 NV-2003
Performance Evaluation• 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)
I. MPEG-1 Streaming with CORP and TCP II. MPEG-1 Streaming with TCP only
0
10
20
30
40
50
60
70
80
0 0.3 0.6 0.9 1.2 1.5 1.8 2.1 2.4 2.7 3
Data receiving rate per each second (Mbps)
Per
cent
age
(%)
Before HandoffAfter Handoff
0
10
20
30
40
50
60
0 0.3 0.6 0.9 1.2 1.5 1.8 2.1 2.4 2.7 3
Data receiving rate per each second (Mbps)
Per
cent
age
(%)
Before HandoffAfter Handoff
* 150KBps bandwidth reserved
33 NV-2003
• 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)
0
10
20
30
40
50
60
70
80
90
100
1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2
Data receiving rate per each second (Mbps)
Per
cent
age
(%)
Before HandoffAfter Handoff
0
10
20
30
40
50
60
70
80
90
100
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
Data receiving rate per each second (Mbps)
Per
cent
age
(%)
Before HandoffAfter Handoff
I. MPEG-1 Streaming with CORP and UDP II. MPEG-1 Streaming with UDP only
* 200KBps bandwidth reserved
Performance Evaluation
34 NV-2003
• 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)
0
10
20
30
40
50
60
70
80
90
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Frame number
PSN
R (d
B)
Handoff0
10
20
30
40
50
60
70
80
90
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Frame number
PSN
R(d
B)
Handoff
I. MPEG-1 Streaming with CORP and TCP II. MPEG-1 Streaming with TCP only
Performance Evaluation
35 NV-2003
• 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)
0
10
20
30
40
50
60
70
80
90
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Frame number
PSN
R (d
B)
Handoff0
10
20
30
40
50
60
70
80
90
0 200 400 600 800 1000 1200 1400 1600 1800 2000
Frame number
PSN
R (d
B)
Handoff
I. MPEG-1 Streaming with CORP and UDP II. MPEG-1 Streaming with UDP only
Performance Evaluation
36 NV-2003
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
37 NV-2003
References[1] B. Adamson, “The MGEN Toolset,” http://manimac.itd.nrl.navy.mil/MGEN, USA, 1999.[2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for
Differentiated Services,” RFC 2475, IETF, 1998.[3] R. Branden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol
(RSVP) – Version 1 Functional Specification,” RFC 2205, IETF, 1997.[4] F. Cheong and R. Lai, “A study of the burstiness of combined MPEG video and audio bitstreams,”
Computer Communications, 21(10), pp. 880-888, 1998.[5] L. deCarmo, “Core Java media framework,” Prentice-Hall, 1999.[6] W. Fenner, “Internet Group Management Protocol, Version 2,” RFC 2236, IETF, 1997.[7] D. L. Gall, “MPEG: a video compression standard for multimedia applications,” Communications
of ACM, 34(4), pp. 46-58, 1991.[8] R. Gordon, “Essential JNI: Java Native Interface,” Prentice-Hall, 1998.[9] R. Gordon and S. Talley, “Essential JMF: Java Media Framework,” Prentice-Hall, 1999.[10] K. Lee, “A Method of Concatenation and Optimization for Resource Reservation Path (CORP) in
Mobile Internet,” M.S. Thesis, ICU, 2000.[11] J. K. Ng, “A reserved bandwidth video smoothing algorithm for MPEG transmission,” Journal of
Systems and Software, 48, pp. 233-245, 1999.[12] C. Perkins, “IP Mobility Support,” RFC 2002, IETF, 1996.
38 NV-2003
References (cont.)
[13] R. R. Pillai and M. K. Patnam, “A method to improve the robustness of MPEG video applications over wireless networks,” Computer Communications, 24, pp. 1452-1459, 2001.
[14] S. C. Sullivan, L. Winzeler, J. Deagen, and D. Brown, “Programming with the Java Media Framework,” John Wiley & Sons, Inc., 1998.
[15] A. K. Talukdar, B. R. Badrinath, and A. Acharya, “MRSVP: A Reservation Protocol for an Integrated Service Packet Network with Mobile Hosts,” Technical Report: DCS-TR-337, Rutgers university, USA.
[16] C. Tseng, G. Lee, and R. Liu, “HMRSVP: a hierarchical mobile RSVP protocol,” Distributed Computing Systems Workshop, 2001 Int’l Conf. on, pp. 467-472, 2001.
[17] “Dynamics – HUT Mobile IP,” http://www.cs.hut.fi/Research/Dynamics, Finland, 2001.[18] “Java Media Framework API Guide,”
http://java.sun.com/products/java-media/jmf/index.html, Sun Microsystems, USA, 1999.[19] “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
specifications: Higher speed Physical Layer Extension in the 2.4 GHz Band,” IEEE Standard 802.11b, IEEE, USA, 1999.
39 NV-2003
Selective Establishment of Pseudo Reservations (SEP) for QoS Guarantees
in Mobile Internet
Kyounghee Lee and Myungchul Kim{leekhe, mckim}@icu.ac.kr
40 NV-2003
Introduction
Mobile Internet environments• Frequent traffic path redirection due to host mobility• Poor communication characteristics
- Higher error rate, lower bandwidth, etc.
General multimedia data characteristics• Intolerant to delay and jitter variance• Error-sensitive
Effects on multimedia steaming in mobile Internet• Latency and packet loss due to handoff• Entrance toward the congested network delay & error
increment Significant QoS degradation
41 NV-2003
Introduction (cont’d)
QoS guarantees in wired Internet• Resource reservation
- Focus on per-flow QoS (for the access networks)- Resource Reservation Setup Protocol (RSVP) [1]
• Class-based packet scheduling- Focus on QoS for flow aggregates (for the core networks)- Differentiated service (DiffServ) [23], Multi-protocol Label Switching
(MPLS) [24]
Mobility issues with RSVP• RSVP signal messages invisibility problem
- Due to tunneling (packet encapsulation) between HA and FA
• Reservation path invalidation
42 NV-2003
Conventional approaches on RSVP with mobility support• Suffer from excessive reservation requirements due to
establishment of multiple advance reservations at all adjacent BSs [4, 5, 8, 10, 11]
• Require considerable functional modifications in the existing Internet protocols and components [6, 7, 9]
Our goals• Supports seamless QoS guarantees in mobile Internet
Resource Reservation Protocol (RSVP) with mobility support• Addresses the excessive advance reservation requirements • Demands minimal changes in the current Internet environments
Introduction (cont’d)
43 NV-2003
Related Work
RSVP tunneling [3]• Packet re-structuring at mobile agents• RSVP signal message invisibility (O), RSVP path invalidation (X)
Mobile RSVP (MRSVP) [4, 5]• Passive reservations at all neighboring cells along a multicast tree
passive reservation functions on all routers in the network• MH is required to have prior knowledge of its mobility
MRSVP extensions • Mahadevan’s approach [8]
- Passive reservations are established between BSs- Reservation path extension infinite extension problem- Passive reservation functions should be equipped on all gateway
routers
44 NV-2003
MRSVP extensions (cont’d)• Hierarchical MRSVP [9]
- Solution for the excessive advance reservations- Passive reservation is established only for an inter-domain handoff- Considerable modifications on the existing Internet (RSVP tunneling &
mobile IP regional registration [12])
Chen’s approach [7]• Predictive reservation & temporary reservation
Paskalis’ approach [6]• Single contact IP address for a MH by dynamically translating between
Local Care-of-Address (LCoA) and Domain CoA (DCoA)• Method only for the access networks
Low latency handoff support with Layer 2 (L2) functionality• Fast handoff mechanism [13] and Proactive handoff [14]
Related Work (cont’d)
45 NV-2003
Proposed Mechanism Selective Establishment of Pseudo Reservations (SEP)
• Pseudo reservation- Advance reservation in SEP- Established only between two neighboring BSs- Established in the same way as a normal RSVP session
• SEP advantages- Movement detection scheme using L2 functionality significant
decrease in the number of required PRPs- Integrates all enhanced features into the leaf BS fewer functional
and structural changes in the existing network components- Reservation load balancing efficient resource management (for
future work)
• Three major steps in SEP- Pseudo Reservation Path (PRP) establishment- Concatenation of Reservation path (CRP) process- Optimization for Reservation path (ORP) process
46 NV-2003
Overall SEP Process
1. PRP establishment 2. Path extension 3. Path optimization
BS_CBS_BBS_A
MH
CH
BS_CBS_BBS_A
MH
CH
BS_CBS_BBS_A
MH
CH
(1)(2)
(3)
: Existing RSVP Session (1), Activated PRP (2), Optimized Reservation Path: Inactivated Pseudo Reservation Path (PRP)
: Traffic forwarding
47 NV-2003
Movement Detection
• Movement detections in SEP– Detects a L2 beacon arrival from a neighboring BS– CRP_initiate message to notify the current BS of the movement– CRP_inform message to start a PRP establishment process
48 NV-2003
CRP Process before a Handoff • When a MH is a sender
BS_C
3.CRP_inform
Reservation path Inactivated PRP CRP-SEP & RSVP control flow
(a)
BS_BBS_A
MH
CH
1.L2 beacon
2.CRP_init
4.RSVP path
5.RSVP resv
BS_C
(b)
BS_BBS_A
MH
CH
PRP
49 NV-2003
CRP Process before a Handoff (cont’d)
• When a MH is a receiver
BS_C
3.CRP_inform
Reservation path Inactivated PRP CRP-SEP & RSVP control flow
(a)
BS_BBS_A
MH
CH
1.L2 beacon
2.CRP_init
4.RSVP path
5.RSVP resv
BS_C
(b)
BS_BBS_A
MH
CH
PRP
50 NV-2003
CORP-SEP Process after a Handoff
BS_C
Reservation path & Activated PRP Inactivated PRPCRP-SEP & RSVP control flow
(a)
BS_BBS_A
MH
CH
BS_C
(b)
BS_BBS_A
MH
CH
Activated PRPPRP
1.CRP_activate
Traffic forwarding
51 NV-2003
ORP Process• ORP process can be performed
– Unicast address vs. multicast address
• ORP process using multicast address
1.CRP_release
2.Path teardownBS_B
(a)
BS_A
MH
CH
Activated PRP
Join
BS_B
(b)
BS_A
MH
CH
BS_B
(c)
BS_A
MH
CH
Optimized path
Reservation path & Activated PRP CRP-SEP, RSVP & IGMP control flowTraffic forwarding
52 NV-2003
Performance Evaluation• Testbed configuration
- OS: FreeBSD 4.2, Linux ker 2.2.12 & 2.2.14- Mobile IP: HUT Dynamics 0.8.1- RSVP: ISI release 4.2a4 with ALTQ 3.0
CH
R
BS2
CH : Correspondent HostR : Gateway RouterHA/FA : Home/Foreign AgentBS : FA + APAP : Access PointRA : Reservation AgentMH : Mobile Host : NIC (IEEE 802.3) : NIC (IEEE 802.11b) : Hub : RSVP sessionSEP
Mobile IPFA Module
Routing & TrafficScheduling module
BS1
Wired Subnet A
MH
Wired Subnet B
Wireless Subnet C Wireless Subnet D
HA
RSVP
53 NV-2003
• Handoff latency in Mobile IP and SEP (measured & estimated)
L2 beaconarrives
( 36) Time (ms)
0
L2 roamingMIP solicitation & advertising MIP binding
update
MIP registrationrequest
Handoffcompletion
( 0)
Estimated MIP handoff latency
( 0)
PRP establishing time( 22)
PRP activation& forwarding
( 11)
Performance Evaluation
54 NV-2003
• Average data transmission rates– 250 kbytes (2000 kbps) reserved– 250 data packets per sec, each packet 1024 bytes– Link capacity: 9,300 (wired) vs. 4,700 (wireless) kbps 9000 kbps
background traffic
800
1000
1200
1400
1600
1800
2000
2200
2400
Time (100 ms)
Ave
rage
Dat
a R
ate
(kbp
s)
SEP
RSVP
Handoff to the congested cell
Performance Evaluation
55 NV-2003
• Simulation environment– Simulator – NS2.1b9a– 7 x 7 mesh model– Communication range of each BS: 250m– Overlapped area size: 150m– L2 beacon interval: 100ms– Host movement: random direction mobility model [21]
BS00
(0, 0)
(2600, 2600)
BS01 BS06
BS60
100 150
0
500
1000
1500
2000
2500
0 500 1000 1500 2000 2500
Performance Evaluation
56 NV-2003
• Average PRP requirements– 0.49 (SEP) vs. 4 (MRSVP, CORP)– 0.11 (HMRSVP)
* The number of reachable BSs is zero when a MH is moving around the border area of the simulation network
-0.5
0
0.5
1
1.5
2
2.5
3
3.5
0
500
1000
1500
2000
2500
3000
Simulation time (s)
Num
ber o
f rea
chab
le BS
s
Performance Evaluation
57 NV-2003
• Reservation blocking rates– Probability for a MH to fail to make a new RSVP session ( the amount of the required advance reservations)
0
5
10
15
20
25
30
35
40
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Reservation requirements (offered load)
Rese
rvat
ion b
lockin
g pr
obab
ilities
(%)
HMRSVPSEPMRSVP , CORP
Performance Evaluation
58 NV-2003
• Reservation session loss rate– Probability for a MH to lose its reservation path after a handoff
- SEP > HMRSVP (when the offered load is high) Insufficient advance reservations in HMRSP- SEP > MRSVP (when the offered load is low) less PRP requirements in SEP
Performance Evaluation
59 NV-2003
0
10
20
30
40
50
60
70
80
90
100
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1Reservation requirements (offered load)
Rese
rvat
ion
sess
ion
com
plet
ion
rate
s (%
)
HMRSVP(1)SEP(1)MRSVP(1)HMRSVP(5)SEP(5)MRSVP(5)
• Reservation session completion rate– Probability that a MH can complete a RSVP session without any
reservation blocking or session loss• SEP outperforms HMRSVP as
- the offered load in the network increases- the average number of handoffs increases during a reservation
session
Performance Evaluation
60 NV-2003
Conclusions & Future Work SEP - seamless QoS guarantees in mobile Internet
• RSVP with mobility support- pseudo reservation, reservation path extension & optimization
• Movement detection using L2 functionality- significant decrease in the number of required PRPs
• Fewer functional & structural changes in the existing Internet components and protocols• SEP outperforms the conventional approaches in reservation session
loss rate and completion rates especially as• the offered load in the network increases • the average number of handoffs increases during a reservation session
• Efficient network resource management- MH can choose its next BS according to the amount of available resources
in the reachable BSs
Future Work• Performance evaluation in SEP due to reservation load balancing
61 NV-2003
References• [1] R. Branden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol
(RSVP) – Version 1 Functional Specification”, RFC 2205, IETF, Sep. 1997.• [2] C. E. Perkins, “IP Mobility Support”, RFC 2002 on IETF, Oct. 1996.• [3] A. Terzis, M. Srivastava, L. Zhang, “A Simple QoS Signaling Protocol for Mobile Hosts in
the Integrated Service Internet”, IEEE Proceedings, Vol. 3, 1999.• [4] A. K. Talukdar, B. R. Badrinath, A. Acharya, “MRSVP: A Reservation Protocol for an
Integrated Service Packet Network with Mobile Hosts”, Tech report TR-337, Rutgers university.• [5] A. K. Talukdar, B. R. Badrinath, A. Acharya, “On Accommodating Mobile Hosts in an
Integrated Services Packet Network”, in proc. IEEE Conference on Computer Communications (INFOCOM), Apr. 1997.
• [6] S. Paskalis, A. Kaloxylos, and E. Zervas, “An efficient QoS Scheme for Mobile Hosts”, 26th Annual IEEE Conference on Local Computer Network (LCN 2001), pp. 630-637, 2001.
• [7] W. Chen and L. Huang, “RSVP Mobility Support: A Signaling Protocol for Integrated Services Internet with Mobile Hosts”, in proc. IEEE Conference on Computer Communications (INFOCOM), Part vol. 3, pp. 1283-1292 Vol 3, 2000.
• [8] I. Mahadevan and K. M. Sivalingam, “Architecture and Experimental Results for Quality of Service in Mobile Networks using RSVP and CBQ”, ACM Wireless Networks 6, pp. 221-234, Jul. 2000.
• [9] C. Tseng, G. Lee, and R. Liu, “HMRSVP: A Hierarchical Mobile RSVP Protocol”, International Workshop on Wireless Networks and Mobile Computing (WNMC2001), Apr. 2001.
• [10] K. Lee, M. Kim, S. T. Chanson, C. Yu, J. Lee, “CORP- A Method of Concatenation and Optimization for Resource Reservation Path in Mobile Internet”, IEICE Transactions on Communications, pp. 479 – 489, Vol. E86-B, No. 2, Feb. 2003.
62 NV-2003
References• [11] M. Lee, K. Lee, T. C. Thang, N. N. Thanh, M. Kim, Y. Ro, J. Lee, “MPEG Streaming over
Mobile Internet”, IS&T/SPIE’s 14th Annual Symposium, Electronic Imaging 2002, Jan. 2002.• [12] E. Gustafsson, A. Jonson, C. E. Perkins, “Mobile IP Regional Registration”, Internet Draft
on IETF, Oct. 2002.• [13] K. E. Malki, P. R. Calhoun, T. Hiller, J. Kempf, P. J. McCann, A. Singh, H. Soliman, S.
Thalanany, “Low Latency Handoffs in Mobile IPv4”, Internet Draft on IETF, Jun. 2002.• [14] P. Calhoun, “FA Assisted Hand-off”, Internet Draft on IETF, Mar. 2000.• [15] W. Fenner, “Internet Group Management Protocol, Version 2”, RFC 2236 on IETF, Nov.
1997.• [16] “WaveLAN”, http://www.agere.com/client/wlan.html• [17] “ALTQ: Alternate Queueing”, http://www.csl.sony.co.jp/person/kjc/kjc/software.html• [18] “Dynamics – HUT Mobile IP”, http://www.cs.hut.fi/Research/Dynamics• [19] “RSVP Code rel4.2a3”, ftp://ftp.isi.edu/rsvp/release/• [20] “MGEN: The Multi-Generator Tool”, http://manimac.itd.nrl.navy.mil/MGEN/• [21] T. Camp, J. Boleng, V. Davies, “A Survey of Mobility Models for Ad Hoc Network
Research”, Wireless Communication & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends and Applications, vol.2, no.5, 2002.
• [22] “The Network simulator – NS-2”, http://www.isi.edu/nsnam/ns/• [23] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture for
Differentiated Services”, RFC 2475 on IETF, Dec. 1998.• [24] E. Rosen, A. Viswanathan, R. Callon, “Multi-protocol Label Switching Architecture”, RFC
3031 on IETF, Jan. 2001.