IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0246-00-0000 Title: Command Service Date Submitted: Month, NN, 200x Presented at IEEE 802.21 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-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 stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf>  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-07-xxxx-00-0000

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-00-0000

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-00-0000

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-00-0000

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-00-0000

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 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 For request and indication, current parameters are defined and there seems that no changes are required, except we need to understand the handover id For response and confirm, it is a good idea to combine available resource set and IP configuration to optimize the message length. “Handover status” should be renamed but the idea of “accept” or “reject” may be good. “Handover allowed” is one suggestion. However, there should be explicit text to describe it. Also “handover status” should be under “Preferred Candidate List”. 21-07-xxxx-00-0000

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 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) Junghoon will check whether “Target POA” is redundant for “Request and Indication” and discuss with Ajay. “Link Action” is local in scope. Also for Response/Confirm Junghoon will discuss with Ajay on “current link identifier” 21-07-xxxx-00-0000

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 Current Link Identifier Status The description and corresponding remedy do not match 21-07-xxxx-00-0000

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 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 ‘Requested resource set’ and Requested Resource List” are similar. There is no need for IP configuration data in Response/confirm. In general, these parameters may already be fixed in D5.2. 21-07-xxxx-00-0000

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 Link Action Result List Handover Status Status Link action is remote in scope and it is required. There is no need for additional parameters. 21-07-xxxx-00-0000

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 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 This primitive is for resource query not for resource reservation. So there is no need for “Reserve resource” in Request/Indication. Response/Confirm currently does not require candidate link list since the query is for network level resource not per POA. 21-07-xxxx-00-0000

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 Status Status Pl. refer to contribution -0160-03, 0164-02 and discuss with Junghoon and Juan Carlos 21-07-xxxx-00-0000

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 Current Link Identifier Resource Status Status It does not make sense to add “Target Link Identifier” in Request/Indication and also “Resource Status” is required for “Response/Confirm” since this implies resource retention. However, “Status” can be removed. 21-07-xxxx-00-0000