Transcript Fast Handovers for Mobile IPv6

IEEE VTC, 2006
An Integrated Handover Scheme for
Fast Mobile IPv6 over IEEE 802.16e
Systems
Jinsoo Park,
Dong-Hee Kwon and
Young-Joo Suh
1
Introduction
•
•
The IEEE 802.16e has its own link layer (L2) handover algorithm,
but, due to Internet Protocol (IP) addressing, a network layer (L3) handover
algorithm is also required to support the mobility.
•
Mobile IPv6 is not suitable
– the long latency for movement detection, binding update, and new care-of address
(NCoA) configuration
•
Fast Handovers for Mobile IPv6 (FMIPv6) is proposed to reduce the handover
latency
– by executing those time consuming processes when a mobile station (MS) is still
present on the current link
– with the help of timely generated L2-trigger.
•
but deciding when to generate the L2-trigger is a difficult problem and left as an
implementation specific
2
Introduction (cont’d)
• During the FMIPv6 handover,
– if the MS could not receive the FBack message while it is
still in the current network
• due to the imprecise L2-trigger generation time,
– it should change its handover mode from predictive to
reactive,
• which may significantly degrade the handover performance.
3
Background
- Mobile IPv6 Fast Handovers over IEEE 802.16e
Decision to
handover
Change link
4
Background (cont’d)
• this work primarily focuses on the coordination of
control messages for handovers between the IEEE
802.16e system and FMIPv6,
• and only provides a procedural description on how
FMIPv6 could be implemented on link layers
conforming to the IEEE 802.16e standard.
5
Proposed Scheme
• Basic idea
– a BS can notify its access router (PAR) of an impending handover and
• based on the MAC management messages exchanged with a MS
– make PAR initiate the L3 handover on behalf of the MS.
• reduce the handover latency
• solve the problems related to the imprecise L2-trigger
generation time, because
– the L3 handover is always initiated in a predictive manner at the
network side and
– does not require any interventions of the MS
• minimize the packet loss
– because the PAR buffers the packets destined for the MS until the
tunnel is set up
6
The proposed scheme (single tunnel)
Decision to
handover
Change link
7
The proposed scheme (multiple tunnel)
8
Proposed Scheme (cont’d)
• some of the existing control messages in FMIPv6 are
removed
– such as RtSolPr, PrRtAdv, FBU, FBack, and FNA
• PAR configures the NCoA using the MAC address of the MS
and the network prefix of NAR on behalf of the MS
– Used in HI message
– may formulate multiple NCoAs and set up multiple tunnels
• NAR send the unsolicited Router Advertisement (RA) with
Neighbor Advertisement Acknowledgement (NAACK) option
to the MS
– NAACK carrys NCoA
9
Proposed Scheme (cont’d)
• PAR may receive the HO-CONFIRM
message before the completion of the
HI/HAck message exchange with NAR
• In this case, PAR starts buffering the packets destined for the
MS
– until the completion of the HI/HAck message exchange
– forwards them right after the tunnel is set up
• the MS may still reside in the current network even after the
tunnel is created
• the tunnel is inactive and activated only when PAR receives
the HO-CONFRIM message,
– which is generated in response to the MOB_HO-IND message from
the MS
10
Performance Evaluation
- Performance Analysis
• TL2 : Time required to perform a 802.16e L2 handover
– MOB_HO-IND ~ (unsolicited) REG-RSP
• TL3 : Time required to perform a FMIPv6 L3 handover
– FBU (HO-NOTIF) ~ FBack (HAck)
• TI : Time difference from the time receiving MOB_BSHO-RSP
to the time sending MOB_HO-IND
• TF : Time required to send a FNA message after a 802.16e L2
handover
– (unsolicited) REG-RSP ~ FNA
• TD : Time required to receive the first packet from NAR after
NAR recognizes the MS’s attachment to the link
11
12
Performance Evaluation
- Simulation Result
• Use ns2
– implement the IEEE 802.16e MAC and
– The scheme in the IETF-Internet Draft and the proposed scheme are
implemented.
• The L2 handover latency is
chosen from the uniform
distribution: [100ms, 115ms]
• DAD time is selected from
the uniform distribution:
[900ms, 1000ms]
• One downlink CBR (100kbps)
from CN to MN
13
=TF,
less than 20ms
In our simulator,
4~5ms
14
Performance Evaluation
- Simulation Result (cont’d)
• Add background uplink traffic
– the influence of the number of uplink flows on the total
handover latency (mostly on TF)
– All flows generate CBR traffic at the rate of 100Kbps, and
• a BS schedules the transmission order of uplink
flows as round-robin style
15
16
Conclusion
• an integrated Fast Mobile IPv6 handover scheme over the
IEEE 802.16e system
– L3 handovers are performed without the intervention of MSs
– the L3 handover is automatically initiated based on the MAC
management messages of IEEE 802.16e, it is possible to reduce the
handover latency
• the proposed scheme is less influenced by the uplink
background traffic volume
• as PAR could acknowledge the exact link switching time and
the destination to which a MS performs a handover, the
proposed scheme eliminates the packet loss
• By numerical analysis and simulation study, we show that the
proposed scheme shows an improved handover performance
over the existing scheme
17
comments
• 解除Fast handover for Mobile IPv6裡predictive與
reactive的迷思
• 與HiMIP概念類似, 由network端做所有flow path
redirection的工作
– But no QoS consideration involved
• 可以模仿其分析與實驗
18