IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0087-01-0000 Title: Sponsor ballot Comment Resolutions Date Submitted: March 19, 2008 Presented at IEEE 802.21 session #25 in Orlando Authors or Source(s): Qiaobing Xie, Subir Das Abstract: This presentation captures suggested resolutions to several comments. 21-07-0xxx-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. 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 <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-0xxx-00-0000

Comment #23 Comment #23: The draft standard is silent on what options in 802.11, 802.16, etc. it requires for basic functionality, in mentioning 'suitable amendments'. The draft is silent on what options in other standards it cannot work with. The 802.11 WEP is an example, and the Frequency Hop PHY is another. Proposed text change: Delete old text: “ (PHY/MAC Features) Bit 0: Access point (AP) Bit 1: Independent station (not an AP) Bit 2: FHSS PHY for 2.4GHz band Bit 3: DSSS PHY for 2.4GHz band Bit 4: IR PHY Bit 5: OFDM PHY Bit 6: High-speed PHY Bit 7: Multi-domain operation capability implemented Bit 8: Extended Rate PHY (ERP) Bit 9: Spectrum management operation supported Bit 10: Regulatory class capability implemented Bit 11: QoS Supported Bit 12: Robust Secure Network (RSN) supported Bit 13-63: (Reserved) .” 21-07-0xxx-00-0000

Comment #23 (cont.) Proposed text change: New text: “Bits 0-15 shall correspond to the Capability Information field as defined in Figure 7-22 in IEEE 802.11-2007. Additional IEEE 802.11 capability information, when becomes available, can be indicated in TYPE_EXT.” 21-07-0xxx-00-0000 4

Comments #82/83/84/85 Proposed text change: Use the following new text: These bits provide hints at various high level capabilities of an access network. Bitmap Values: Bit 0: Security – When set to ‘1’, indicates that some level of security is supported; Otherwise, no security support is available. Bit 1: QoS Class 0– When set to ‘1’, indicates that QoS for class 0 is supported; Otherwise, no QoS for class 0 support is available. * Bit 2: QoS Class 1 – When set to ‘1’, indicates that QoS for class 1 is supported; Otherwise, no QoS for class 1 support is available. Bit 3: QoS Class 2 – When set to ‘1’, indicates that QoS for class 2 is supported; Otherwise, no QoS for class 2 support is available. Bit 4: QoS Class 3 – When set to ‘1’, indicates that QoS for class 3 is supported; Otherwise, no QoS for class 3 support is available. Bit 5: QoS Class 4 – When set to ‘1’, indicates that QoS for class 4 is supported; Otherwise, no QoS for class 4 support is available. Bit 6: QoS Class 5 – When set to ‘1’, indicates that QoS for class 5 is supported; Otherwise, no QoS for class 5 support is available. Bit 7: Internet Access – When set to ‘1’, indicates that Internet access is supported; Otherwise, no Internet access support is available. Bit 8: Emergency Services – When set to ‘1’, indicates that some level of emergency services is supported; Otherwise, no emergency service support is available. Bit 9: MIH Capability – When set to ‘1’, indicates that MIH is supported; Otherwise, no MIH support is available. Bit 10-31: (Reserved) * Note that the definitions of the QOS classes are according to ITU Y.1541.[ref] 21-07-0xxx-00-0000 5

Comments #90 Comment #90: Annex B.3.11: The MIHF_ID definition is incomplete. It should state whether there the MIHD_ID is required to be globally unique or not. Also, there should be a complete list of acceptable IDs and not just the FQDN/NAI examples.. Proposed text change: Old text: “The MIHF Identifier. MIHF-ID shall be invariant even if the device obtains different interfaces or other components in its registration lifetime. For example, MIHF-ID may be an FQDN or NAI.” New Text: “The MIHF Identifier: MIHF-ID is an NAI. If MIHF entity resides in the network then MIHF-ID is the FQDN or IP address of the entity that hosts the MIH Services.” 21-07-0xxx-00-0000 6