21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Command Service Date Submitted: Month, NN, 200x Presented at IEEE session #NN in City Authors or Source(s): Ajay Rajkumar, David Faucher Abstract: This contribution tries to streamline the currently defined commands in the draft and remove fields that are redundant or add fields that would be necessary for the usefulness of the command.

21-07-xxxx IEEE presentation release statements This document has been prepared to assist the IEEE 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 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 Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

21-07-xxxx Proposed Changes related to MIH Handovers  MN initiated handovers.  Potential Changes Mapping response to request? Pre-Allocation/Reservation of resources? Add new N2N handover commit message?

21-07-xxxx Changing MN Initiated Handover (proposal)  Draft: ask network about the availability of its resources. Proposal: ask network whether it can support a specific set of resources. For negative response (i.e. can’t support resources) the network has the option of returning what it can support. For example, the former asks what flavors of ice cream are available while the latter asks do you have chocolate, vanilla and strawberry (no, but I can support chocolate and vanilla). Pros network reveals minimal information smaller response size (no need to list every available resource) allows for more detailed queries (that are relevant to the MN) Cons places more control into the hands of the service provider

21-07-xxxx Mapping Response to Request (potential proposal)  For MIH User to MIH User messages there is no mechanism for mapping the response to the request. This is because the transaction ID (in the MIH protocol message header) which maps a response to the request is internal to the MIHF. Should some form of message/transaction identifier be added to all MIH handover messages? In fact, should the same value be used for all related handover messages (i.e. per handover)? Otherwise, how does a Network know that a particular commit relates to a previous query (if any)? Add handover identifier to all MIH User to MIH User related handover messages Pros ability to map response to appropriate request no need to include fields in the response that were in the request with pre-allocation/reservation of resources, allows mapping of commit to query Cons ? Note: if left as an implementation detail then MIH User/MIHF would need to be implemented by the same party (or at least agree upon an API) since the MIH_SAP doesn’t contain enough information to map the response to the request. However, that still doesn’t solve the problem with mapping commit to query for pre-allocated/reserved resources.

21-07-xxxx Pre-Allocating/Reserving Resources (potential proposal)  Provides ability to pre-allocate/reserve resources during N2N query stage. Adds pre-allocate/reserve flag to N2N query message Add new N2N_HO_Commit message for candidate notification selected target – prepare for handover other candidates – cleanup any pre-allocated/reserved resources Pros gives originating network control over when/if resources are pre- allocated/reserved eliminate failures for the cases where resources become unavailable between the time of the query and actual commitment to a handover Cons requires new message to notify candidates as to their selection and whether they should release any pre-allocated/reserved resources.

21-07-xxxx MN_HO_Candidate_Query (proposal) Description: Query serving PoS to see if candidate networks can support a handover given the requested resource and IP configuration requirements Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Current Link Identifier (LINK_TUPLE_ID) Candidate Link List (LINK_POA_LIST) Query Resource List IP Configuration Method (with DHCP, FA or Router Address) Requested Resource List (TBD) Requested Configuration (IP with DHCP, FA or Router Address) Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Current Link Identifier Available Resource Set IP configuration Method (with DHCP, FA or Router Address) IP Address Information Status Preferred Candidate List (list of following) Preferred Candidate Link Identifier (LINK_POA_LIST) Requested Resource Status –Availability + [ optional Available Resource List (returned when requested resources not available) ] Requested Configuration Status –Availability + [ optional Available IP Configuration (returned when requested configuration not available) ] Handover Status (e.g. accept, reject code) Status

21-07-xxxx MN_HO_Commit (proposal) Description: Commit to a MN initiated handover from source to target link. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Current Link Identifier (LINK_TUPLE_ID) Target Link Identifier (LINK_TUPLE_ID) Target PoA Old Link Action (which side of link is this referring to? is this MBFB?) Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Current Link Identifier Handover Status Status Since this also replaces the switch command we need to specify some form of handover mode (e.g. make before break)

21-07-xxxx MN_HO_Complete (proposal) Description: MN signals the completion of the handover from source to target link. May be sent to target PoS or original serving PoS. The former will require a registration first. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Source Link Identifier (LINK_TUPLE_ID) Target Link Identifier (LINK_TUPLE_ID) Handover Result (e.g. success, failure code) Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Current Link Identifier Status

21-07-xxxx Net_HO_Candidate_Query (proposal) Description: Query the MN as to its resource and configuration requirements and its willingness to accept one or more suggested target candidates for a handover. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Suggested New Link List (LIST(LINK_POA_LIST)) Query Resource List (QUERY_RESOURCE_LIST) Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Current Link Identifier (LINK_TUPLE_ID) Preferred Link List (LIST(LINK_POA_LIST)) Requested Resource Set Requested Resource List (TBD) Requested Configuration (IP with DHCP, FA or Router Address) Handover Status Status

21-07-xxxx Net_HO_Commit (proposal) Description: Commit to a Network initiated handover from source to target link. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Link Action Set List Source Link Identifier (LINK_TUPLE_ID) Target Link Identifier (LINK_TUPLE_ID) Source Link Action (e.g. data forwarding)  applies to which side of link? Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Link Action Result List Handover Status Status

21-07-xxxx N2N_HO_Query_Resources (proposal) Description: Query target PoS to see if access network can support a handover given the specified resource and configuration requirements. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Candidate Link List (LIST(LINK_POA_LIST)) Query Resource List IP Configuration Method (with DHCP, FA or Router Address) Requested Resource List (TBD) Requested Configuration (IP with DHCP, FA or Router Address) Reserve Resources? Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Resource Status Available Resource Set IP Configuration Methods (with DHCP, FA and/or Router Address) IP Address Information Status Candidate Link List (list of following) Candidate Link Identifier (LINK_POA_LIST) Handover Status Requested Resource Status –Availability + [ optional Available Resource List (returned when requested resources not available) ] Requested Configuration Status –Availability + [ optional Available IP Configuration (returned when requested configuration not available) ] Status

21-07-xxxx N2N_HO_Commit (potential proposal) Description: Commit target to a Network initiated handover (i.e. from the source to target link). Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Source Link Identifier (LINK_TUPLE_ID) Target Link Identifier (LINK_TUPLE_ID) Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Handover Status Status

21-07-xxxx N2N_HO_Complete (proposal) Description: Target PoS notifies the original serving PoS as to the completion status of the handover. Alternatively, the original serving PoS notifies the target PoS as to the completion status of the handover. Request/Indication Destination(request)/Source(indication) Identifier Handover ID? Current Source Link Identifier (LINK_TUPLE_ID) Target Link Identifier (LINK_TUPLE_ID) Handover Result Response/Confirm Destination(response)/Source(confirm) Identifier Handover ID? Current Link Identifier Resource Status Status