1. IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0246-00-0000
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

2. IEEE 802.21 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
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
21-07-xxxx

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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 , and discuss with Junghoon and Juan Carlos
21-07-xxxx

14. 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