1. 21-06-0xxx-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-06-xxxx-00-0000 Title: Network-Initiated Handover Procedure Update Date Submitted: October 28, 2006 Presented at IEEE 802.21 session in Dallas Authors or Source(s): Yan Peng, Jing Liu Abstract: This document amends the procedure of network- initiated handover, and offers a mechanism to handle handover failure which may happen in the procedure by adding corresponding primitives/messages.

2. 21-06-0xxx-00-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 and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> Section 6.3 of the IEEE- SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 http://standards.ieee.org/board/pat/guide.html

3. 21-06-0xxx-00-0000 Background (I) Current Network-initiated Handover Procedure (A1.2)

4. 21-06-0xxx-00-0000 Background (II) In the case of network-initiated handover procedure (in A1.2), after the Serving PoS makes handover target decision, it requests handover commitment to the specified PoA by sending the MIH_Handover_Commit Request message to MN. The MN replies the result of the handover commitment by sending the MIH_Handover_Commit Response message to the Serving PoS. Then the Serving PoS notifies the target PoS of the fact that MN is about to move to the network through the MIH_Handover_Commit Request message. In figure 31, the message sequence of sending MIH_Handover_Commit Request to MN is prior to the MIH_Handover_Commit message exchange between the Serving PoS and the target PoS.

5. 21-06-0xxx-00-0000 The problem is that the target PoS may reject the request of handover via MIH_Handover_Commit Response (with HandoverStatus option set to 0), due to some reasons such as the resources are unavailable now, how the MN could be notified this failure and stop its handover procedure to the target PoS. In the current draft, the Serving PoS has no way to inform the MN the information of rejection, because there is no message exchange between the Serving PoS and MN, after MN sends the MIH_Handover_Commit Response. Problems Description

6. 21-06-0xxx-00-0000 Adjust the message sequence of sending MIH_Handover_Commit Request in figure 31. Solution to this problem

7. 21-06-0xxx-00-0000 In the modified procedure of network-initiated handover, it still exists another problem: after MN receives the handover commitment –MN may also reject the request of handover for the sake of movement or user intervention. –In this case, the target PoS has no way to be notified the fact that the MN won’t handover anymore and does not know whether it needs to release the related context because there is no message exchange between the Serving PoS and target PoS. There is no handover failure mechanism in 802.21 yet. –Both the mobile node and the network may make decisions about connectivity. –The probability of refusing handover in the procedure may be very low. However it cannot be ignored. –802.21 should offer a mechanism and corresponding primitives to handle handover failure. Further Problem

8. 21-06-0xxx-00-0000 Suggested Remedy (I) Solution: –Introduce a pair of messages and corresponding primitives to handle handover failure: MIH_Handover_Cancel Request and MIH_Handover_Cancel Response. –The messages may be used between MIHF of networks, or between MIHF of network and terminal, to indication the cease of subsequent handover procedure. –The disposal status about the release of reserved context and the reason for canceling handover may be included in the messages.

9. 21-06-0xxx-00-0000 Suggested Remedy (II) Network-initiated unsuccessful handover procedure

10. 21-06-0xxx-00-0000 Suggested Remedy (III) Modify step4 of A1.2: A1.2 Network-initiated Handover Procedure ………… The Network-initiated Handover Procedure operates as follows, ………… 4) The Serving PoS decides the handover target based on the resource availability information of candidate networks through the received MIH_Handover_Prepare Response message. The Serving PoS requests handover commitment to the specified network type and PoA by sending the MIH_Handover_Commit Request message to the MN. The Serving PoS also notifies the target PoS of the fact that MN is about to move to the network through the MIH_Handover_Commit Request messages. The MN replies the result of the handover commitment by sending the MIH_Handover_Commit Response message to the Serving PoS. If the MN rejects the request of handover by sending MIH_Handover_Commit Response (with HandoverStatus option set to 0), the Serving PoS may notify the target PoS of the fact that the MN cancels handover and may suggest the target PoS to release the corresponding context by sending MIH_Handover_Cancel Request message. The target PoS replies the result of cancellation by sending the MIH_Handover_Cancel Response message to the Serving PoS.