1. 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 session #25 in Orlando
Authors or Source(s): Qiaobing Xie, Subir Das
Abstract: This presentation captures suggested resolutions to several comments.
xxx

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

3. Comment #23
Comment #23: The draft standard is silent on what options in , , 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 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) .”
xxx

4. 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 Additional IEEE capability information, when becomes available, can be indicated in TYPE_EXT.”
xxx 4

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

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