1. 21-07-0xxx-00-0000 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN:21-07-0084-00-0000-LB1c-handover-issues.ppt Title: Handover Commands Thoughts and Open Issues Date Submitted: March, 2007 Presented at IEEE 802.21 session #NN in Orlando, FL Authors or Source(s): Ad Hoc Abstract: Discuss open issues to address handover related commands

2. 21-07-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-07-0xxx-00-0000 Open Issues-I MIH-Switch MIH-Switch.Req and MIH-Switch.cfm are defined for a simple link handover command for MIH_User either local or remote, issues to switch req from one link type to another Has an overlapping functionality with MIH-net-ho-candidate-commit Command consumed by MIHF and issues individual setup and teardown commands to two links involved … but session(s) handover does not happen just by switching the links. MIHF has no way to direct the packets to the target link => routing decision lies within the MIH user Does not have complete messaging (ind and resp are missing), instead link_handover_complete is used for that. Thoughts from Adhoc Merge the MIH-Switch.req and MIH-Switch.cfm functionality with MIH-NET-HO-Candidate-Commit Add a bit to include make-before-break and break-before-make in old-link-actions or the parameter as HO-mode from MIH- switch primitives?

4. 21-07-0xxx-00-0000 Open Issues-II MIH-Configure-Link MIH-Configure-Link.Req and cfm Parameters need to be reconsidered Some are duplicate (suspend_driver, link_id and disable_xmitter) What is current-address? Is this an i/f to change the MAC address of the interface? Rename operation_mode to power_management_mode? Thoughts from adhoc Delete the following params Disable_transmitter (same as operation_mode = power_down) link_id (redundant) Current_address (no use case) Suspend_driver (redundant, same as operation_mode) Add the following POWER_UP in operation_mode

5. 21-07-0xxx-00-0000 Open Issues-III MIH-Link-Handover-Complete Has two functionalities Response indication to MIH-Switch (inter-technology) Indication of intra-tech handover of a link change (e.g. 802.11r handover or plainly 802.11(i) reassociation) Commonality to MIH-MN-HO-Complete MIH-MN-HO-Complete is originated from MIH-user level to the peer and is a MIH command (req/resp) MIH-Link-HO-Complete is an event from MIH to MIH user Thoughts from adhoc Delete references to MIH-Switch (keep the rest) Can we somehow combine Mih-link-ho-complete and Mih- mn-ho-complete ? Albert’s law of commands and events!

6. 21-07-0xxx-00-0000 Open Issues-IV MIH-NET-Handover commands Minor technical comments for correction Corrections in message directions Test updates reflecting the split

7. 21-07-0xxx-00-0000 Open Issues-V MIH-Network-Address-Information Information/parameters same as what can be carried in information services request, then why do we need this? Two Usage Scenarios envisioned MIHF PoS in candidate network can provide upto date information via the serving link IS req/resp can be used for this purpose! Just use PoS as the IS server (or partial IS server) Any available transport can be used (if reachable, of course) MIHF PoS in candidate network can provide upto date information via the candidate link Pre-association IS req/resp query can be used in both 802.11 and 802.16 Again, the IS resp could be from PoS