IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-06-0xxx-00-0000 Title: Handover flow diagram for abnormal handover case Date Submitted: December 19, 2006 Presented at IEEE 802.21 session in London, UK Authors or Source(s): Junxiang Guo, Yan Peng, Bin Xia Abstract: This contribution proposes handover flow diagram for abnormal handover case. 21-05-0822-02-0000

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-05-0822-02-0000

Background In current draft, MN can discover and obtain information of a list of neighbor PoAs, so when handover decision is made MN can have multiple choices of target PoAs, but the current draft does not allow the user to initiate a second handover after an initial handover failed, e.g. when MIH_ Net_HO _Candidate_Query Reponse, or MIH_MN_HO_Candidate _Commit Response is received by MN or serving PoS and they include parameters indicating handover failure, then the handover process will be ceased finally, this does not allow the MN or serving PoS to perform handover to another suitable candidate neighbor PoA. So it does not fully make use of the result of PoA discovery and scanning. Current handover procedure is unefficient and will cause higher handover failure ratio. 21-05-0822-02-0000

Proposal Here we suggest three flow diagrams for two types of handover failure case: MIH_ Net_HO_Candidate_Query Reponse: HandoverAck=0: Abort Handover MIH_MN_HO_Candidate_Commit Response: HandoverStatus=0: Abort Handover 21-05-0822-02-0000

Proposal-Handover failure case 1 MIH_ Net_HO_Candidate_Query Reponse: HandoverAck=0, Abort Handover For this case MN will initiate another handover process to another suitable target PoA. The following is the handover flow diagram: 21-05-0822-02-0000

Proposal-Handover failure case 1 21-05-0822-02-0000

Proposal-Handover failure case 2 MIH_MN_HO_Candidate_Commit Response: HandoverAck=0, Abort Handover For this case MN will initiate another handover process to another suitable target PoA The following is the handover flow diagram: 21-05-0822-02-0000

Proposal-Handover failure case 2 21-05-0822-02-0000

Proposal-Handover failure case 2 (Continued) 21-05-0822-02-0000

Proposal-Handover failure case 2- optimized MIH_MN_HO_Candidate_Commit Response: HandoverAck=0, Abort Handover For this case MN will issue MIH_MN_HO_Candidate_Commit to another suitable target PoA, i.e. MN reuses the previous Initiate process result and needs not initiate another handover process again. The following is the handover flow diagram: 21-05-0822-02-0000

Proposal-Handover failure case 2- optimized 21-05-0822-02-0000

Proposal-Handover failure case 2- optimized 21-05-0822-02-0000

Thank you! 21-05-0822-02-0000