IEEE 802 21 MEDIA INDEPENDENT HANDOVER DCN 21

IEEE 802. 21 MEDIA INDEPENDENT HANDOVER DCN: 21 -06 -0782 -01 -0000 Title: LB 1 a Comment Resolution #2339 and #234 Date Submitted: November 13, 2006 Authors or Source(s): Miriam Tauil, Y. Alice Cheng, Subir Das, and Yoshihiro Ohba, Abstract: This contribution proposes few options and recommendations for discussion and adoption as appropriate

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/sect 6. html#6. 3> and in Understanding Patent Issues During IEEE Standards Development http: //standards. ieee. org/board/pat/guide. html>

Comment 2339 • Comment: – Its not clear why ACK-Req/ACK-Rsp are needed. • Commenter’s suggested remedy: – Include some explanation as to why this feature is needed as part of MIH Protocol or remove this feature. • During Ad Hoc Meeting, a broader question was raised: – Is the acknowledgement mechanism as described in the draft needed?

MIH Acknowledgment Mechanism • MIH protocol sends an acknowledgement (ACK message) when receiving a message that requires acknowledgement (e. g. ACK bit set) • MIH protocol retransmits the MIH message if ACK is not received.

Purpose of ACK • For reliability • For delaying the request retransmission. • Any more?

Acknowledgement Features in the Current Draft Optional – to set ACK-Req bit – to retransmit message (with the same transaction ID), if ACK is not received Mandatory – to send an ACK message if destination node received a message with ACK-Req set.

Acknowledgement - is it needed? • For Unreliable Transport – Provide MIH Protocol Level Reliability • If Transport is Reliable, ACK mechanism may not be needed – However, it is not clear whether transport is reliable or not • L 2 transport protocols are mostly reliable but not all L 3 transport protocols are

Suggested Options regarding Acknowledgment Feature • Possible Options: – Option 1: “ACK Feature” implementation is mandatory • For unreliable transport, Ack-bit set is optional. But still need to respond with ACK if Ack. Req set • For reliable transport, Ack-bit shall not be set – Option 2: “ACK Feature” implementation is not mandatory • “ACK Feature” is discovered during MIH Capability Discovery

Option 1 Leave as is, in current draft and add some clarifying text Pros: – Flexibility to use ACK feature. – Simplicity for implementations of MIH protocol over reliable transport – For unreliable transport, MIH retransmits the message instead of MIH user/application • Otherwise, each message is a new transaction for MIH User. Cons: – Extra ACK message might be sent if response message was not immediately available. – Diversity of the definition of the MIH protocol, based on transport layer used.

Option 2 • Mechanism to specify support of “ACK feature”: – Designate one of the reserved bits in the fixed header to specify Support/No Support of “ACK feature”. – Add more functionalities on the MIH Capability Discovery Pros: – Simplicity for implementations of MIH protocol Cons: – Need mechanism to specify support for the “ACK feature”.

Comment 2341 Comment: In the case of L 3 transport, the actual transmission of the packet on the air/wire may be constrained by the operation of the L 3 protocol, for example, because the protocol imposes congestion or flow control. Note also that RTT information may not be available at the MIH application layer so it may be impossible to tune timers to take it into account. Commenter’s Suggested Remedy: Note up front that the RTT information may not be available, and that immediate retransmission by an application may suffer from unpredictable delay introduced by the transport layer.

Comment 2341 Draft Text: A source MIH node may start a timer at the time of sending …. The value of the timer may depend on the RTT between the 2 nodes. Suggested Text: A source MIH node may start a timer at the time of sending …. The value of the timer may depend on the RTT between the 2 nodes, nodes if the RTT is available.

Comment 2341: Discussion Second part of the suggested remedy. Discussion: – If the RTT is not available it does not imply that the estimated or assumed RTT is 0, or the retransmission timer is 0 • Recommendation – No need to add a warning saying that not to immediately retransmit. – Suggested text earlier should be sufficient

Thank You