21-07-xxxx-00-0000

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

IEEE 802.21 presentation release statementsThis 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> 

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• 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-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• 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-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• Handover ID?• Current Link Identifier• Status

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• 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-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• Handover ID?• Link Action Result List• Handover Status• Status

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• 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-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 ID?• Handover Status • Status

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• Handover ID?• Current Link Identifier• Resource Status• Status