1. 21-07-0433-00-00001 IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-07-0433-00-0000 Title: Suggested remedy for SB Comments 598/599/610/611 Date Submitted: November 15, 2007 Presented at the IEEE 802.21 session in Atlanta, GA Authors or Source(s): Qiaobing Xie, Srini Sreemanthula Abstract: This presentation captures in principle a suggested resolution to comments 598/599/610/611

2. 2 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. This is a contribution by the National Institute of Standards and Technology and is not subject to copyright in the US. The contributors do not have the authority to override the NIST policy in favor of the IEEE 802.21 policy. 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 http://standards.ieee.org/board/pat/faq.pdf> Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf 21-07-0433-00-0000

3. Page 39, Line 15 Comment # 599: Failure to transmit data is not same as the lost data. Suggested Remedy: Agree. Replace “lost data” with “unsent data” when describing failure to transmit data 21-07-0433-00-0000

4. Page 39, Line 30 Comment # 598: It is incorrect to say that the transmission status can be verified on by higher layer timeouts. Currently, all link layers provide indications for successful transmission of the frames in the L2 buffer. Suggested Remedy: Agree. Clarify in the description that what the higher layer timeouts verify is the end-to-end delivery status of the data (i.e., not the local transmission status of the data). 21-07-0433-00-0000

5. Page 71, Line 54 Comment # 611: MIH is not the only way through which the higher layers and link layers interact with each other. User place functions don't need MIHF involvement. It is logical and perfectly possible for upper layer buffers to receive frame delivery indications from the link layers. Suggested Remedy: Disagree with removing the section. 1) It is never agreed upon to limit MIHF to only control planes (as shown in Figure 1, Figure 4, Figure 5, etc). 2) Even though most media types already have their own native mechanism for similar indication, this MIH link primitive is a generic primitive. The value for having a generic link primitive that can be mapped to a media-dependent one is well established (the reason behind 802.21 MIH_Link_SAP definition). 21-07-0433-00-0000

6. Page 72, Line 1 Comment # 610: This seems to assume a nonexistent packet identifier common at both higher layers and link layers. TCP/IP layer uses its own sequence numbers which are not visible to MAC layers while MAC layer uses its own sequence numbers for link acknowledgements. What packet identifier is supposed to be used here? Suggested Remedy: 1) Further clarify that the packet identifier is a container structure whose syntax and semantics will be decided by the upper layer (i.e., the user/subscriber of this event). MIHF and link layer just pass and return it and do not need to understand the syntax and semantics. 2) Consider adding a primitive to show explicitly that this packet identifier is passed along with the outbound data from the upper layer. 21-07-0433-00-0000