IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-084-02-0000 Title: Sponsor ballot Comment Resolutions Date Submitted: March 17, 2008 (revised on April 16, 2008) Presented at IEEE 802.21 session #25 in Orlando Authors or Source(s): Nada Golmie Abstract: This presentation captures suggested resolutions to comments #34, #39, #40, #69, #70, #84, #101,#105-#114. 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

Comments #34, #39, #40 Comment #34: Annex B-4: Packet Error Rate ignores multicast traffic, but some MNs care about multicast traffic. Proposed resolution: Add a Multicast error rate indication. Decision: Accept in principle The packet error rate is a measure of how many packets are received in error. The multicast counters available in 802.11K MulticastReceivedFrameCount and MulticastSentFrameCount can help measure a Multicast Packet Loss Ratio. Add on page 175, line 57: “2: Multicast Packet Loss Rate 3-255: (Reserved)” Comment#39,#40:Annex H.1: Packet Error Rate ignores multicast traffic, but some MNs care about multicast traffic. Proposed resolution: Discussion should note these are unicast parameters, unrelated to multicast traffic. Decision: Accept in principle / No change is required Note on page 247 line 50 states the proposed resolution: “Note: the parameters in this section are unicast parameters that are unrelated to multicast traffic” 21-07-0xxx-00-0000

Comment #101 Comment: Annex H: The definition of Link Packet Error Rate is ambiguous since it does not state whether re-transmissions are included or not included when making the measurement. If re-transmissions are included, then the definition should state that not all technologies (e.g., 802.11) support transfer of errored packets. Proposed resolution: clarify text Decision: Accept Add on page 242 line #62: “ … and the total number of frames transmitted including frames that are re-transmitted.” 21-07-0xxx-00-0000

Comment #105 Comment: Annex H.2: Table H-1 and associated text in clause H.3 is not a sufficient specification for using 802.11 features to measure throughput. This annex must provide equations or other normative text to describe how this is to be done. Otherwise different manufacturers will implement the metrics differently. While one could argue this is sufficient for local MIHF, it clearly will not work for remote MIHF. Remote MIFH's may received throughput measurements/metrics from a variety of MNs or PoSs from different manufactures and will otherwise have no method for an "apples-to-apples" comparison of the metric. Proposed resolution: Provide equations or normative methods by which throughput is to be computed. Decision: Accept Add in Table H-1 on page 245 line 10 column 1: “Not currently supported. Measurement is defined as the total number of octets transmitted / Measurement duration.” 21-07-0xxx-00-0000

Comment #106 Comment: Annex H.2: Table H-1 describes using channel utilization as a measure of Throughput. This is technically incorrect since channel utilization also accounts for the effects of interference (i.e., when interference is present, no packets are being transmitted or received by the measuring radio). Proposed Resolution: The 802.11k STA Statistics Request and Report should be referenced. Decision: Accept Remove “channel utilization” from table on page 245 line 10. 21-07-0xxx-00-0000

Comment #107 Comment: Annex H.2: The text states that available admission capacity is an indication of the number of supported CoSs. This is incorrect. The number of supported CoSs on an 802.11e-capable STA is 4 (because there are 4 different access categories, each with their own EDCA parameters) or 8 (arguably 8 if a STA provides some form of differentiated queuing behavior between the two UPs sharing an AC, or if HCCA is employed, there can be at most 8 TIDs); if the STA is not 802.11e capable, then there is only 1 CoS. Proposed Resolution: Fix the text. Decision: Accept Replace “available admission capacity” by “4 for 802.11e”, “8 for HCCA”, “1 for non 802.11e systems” 21-07-0xxx-00-0000

Comment #108 Comment: Annex H.2: Table H-1 refers to a "QoS Metric Report". There is no 802.11 IE name referred to by this name. Proposed Resolution: Change "QoS Metric Report" to "Transmit Stream/Category Measurement Report". Decision: Accept 21-07-0xxx-00-0000

Comment #109 Comment: Annex H.2: Table H-1 states that 802.11 AverageAccessDelay metrics are useful for calculating CoS Average Packet Transfer Delay. This is technically incorrect. AverageAccessDelay parameters measure the waiting time a packet spends in the front of the transmit queue waiting for the medium to become idle and does not for packet re-transmissions. Proposed resolution: Delete the references to AverageAccessDelay metrics. Decision:Accept Table H-1, on page 245, remove lines 34-47 in column 2. Add at line 34 in column 2, “Average Transmit Delay”. Table H-1, on page 245, remove lines 34-35 in column 3 and 4. 21-07-0xxx-00-0000

Comment #110 Comment: Annex H.3.1: There are two PLR types defined: PLR(MPDU) and PLR(MSDU); however, there is no way defined in the 802.21 primitives (e.g., MIH_Link_Get_Parameters.request with LINK_PARAM_QOS) to specify which one to use. Therefore, one of these types should be deleted. PLR(MPDU) should be deleted since in 802.11 this is not directly related to data frames (i.e., a data single data frame may be broken up into multiple fragments) and I would argue that most services (e.g., voice service) care about PLR for MSDUs and not MPDUs. Proposed resolution: Delete the text for PLR(MPDU) and the corresponding text in Table H-1. Decision: Accept Remove lines 57-60 on page 247, lines 1-10 on page 248, and lines 23-24 on page 248. Add the following at line 57 on page 247: “According to IEEE 802.11 a packet is a MAC user data packet or (MSDU).” 21-07-0xxx-00-0000

Comment #111 Comment: Annex H.3.3: The normative text of this Annex defines 3 possibilities for average transfer delay. Only one method should be selected since there is no way defined in the 802.21 primitives (e.g., MIH_Link_Get_Parameters.request with LINK_PARAM_QOS) to specify which one to use. Moreover, if 802.21 permits 3 methods, then different manufacturers will choose different methods resulting in a lack of interoperability. Transmit delay is the most meaning for most services because this is the definition that affects either throughput or latency. These are more service specific (e.g., latency is very appropriate for a voice-service metric) and therefore preferred. Proposed resolution: Delete the text for Access delay and queue delay. Decision: Accept Remove lines 50-52 on page 248. Remove “i)” on line 54 page 248 and replace with “in 802.11k, the transmit delay (MSDU delay) is defined as follows: …” Remove lines 59-65 on page 248 and lines 1-22 on page 249. Remove lines 32-44 on page 249. 21-07-0xxx-00-0000

Comment #112 Comment: Annex H.3.3: The text refers to a "QoS Metric information element". There is no 802.11 IE name referred to by this name. Proposed resolution: Change "QoS Metric nformation element" to "Transmit Stream/Category Measurement Report". Decision: Accept 21-07-0xxx-00-0000

Comment #113 Comment: Annex H.3.3: There are two ATD types defined: ATD(MPDU) and ATD(MSDU); however, there is no way defined in the 802.21 primitives (e.g., MIH_Link_Get_Parameters.request with LINK_PARAM_QOS) to specify which one to use. Therefore, one of these types should be deleted. ATD(MPDU) should be deleted since in 802.11 this is not directly related to data frames (i.e., a data single data frame may be broken up into multiple fragments) and I would argue that most services (e.g., voice service) care about ATD for MSDUs and not MPDUs. Proposed resolution: Delete the text for ATD(MPDU) and the corresponding text in Table H-1. Decision: Accept See comment #111 for resolution. 21-07-0xxx-00-0000

Comment #114 Comment: Annex H.3.4: The text refers to a "QoS Metric information element". There is no 802.11 IE name referred to by this name. Proposed resolution: Change "QoS Metric nformation element" to "Transmit Stream/Category Measurement Report". 21-07-0xxx-00-0000

Comment #84 Comment: Annex B.3.8: There needs to be text (possibly cited by a reference in this table cell) describing the QoS provided by the access network. However, this is not just specifying whether QoS is just over the access link (e.g., an 802.11 WLAN); it doesn't help a MN to determine if it should roam to a new network if the access link has QoS--the MN needs QoS (e.g., for the case of voice service) on the access link, the backhaul link and into the core of the network or a voice gateway to the PSTN. Many hotspots will provide 802.11e (or WMM) QoS in a BSS; however, few today have QoS over the backhaul and few have a QoS connection to the core network. Why would a MN on a cellular call roam to a hotspot that didn't advertise a **voice call** could be carried? We have made this comment in the past and 802.21 WG replied, " The QoS is specified for access link and is not end to end. Specific Application level services are out of the scope. Vendor Specific IEs can be used to specify this." With this response, the WG is failing to provide a solution to the MIH problem. MIIS must provide ***information*** about services provided by higher layers even though MIES/MISC are restricted to operate at the link layer. Proposed resolution: Add normative text in the document to describe what "Bit1: QoS" means and add a citation to that section in this table cell. Decision: Accept Add on line 55 on page 187: Any level of Quality of Service Support Or define bits according to service classes defined in ITU-T 1541 for example: Bit 1: Class 0 Bit 2: Class 1 Bit 3: Class 2 etc. 21-07-0xxx-00-0000 15