1.2.1.1. Dorothy Stanley (Dorothys): I Call the Meeting to Order

May 2007 doc.: IEEE 802.11-07/0684r1

IEEE P802.11 Wireless LANs Minutes of 802.11 Task Group V Wireless Network Management Montreal, Quebec, Canada May, 2007 Date: 2007-05-18

Author(s): Name Company Address Phone email R. R. Miller AT&T 180 Park Ave, Florham Park NJ 973-236-6920 [email protected]

Abstract This document records minutes of the 802.11v Task Group meeting of May, 2007 at Montreal, Quebec, Canada.

Notice: This document has been prepared to assist IEEE 802.11. 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.

Release: 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.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at . Submission page 1 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

1. Monday Morning Session, May 14, 2007

1.2. Opening

1.2.1. Call to Order 1.2.1.1. Dorothy Stanley (DorothyS): I call the meeting to order. 1.2.1.2. Meeting convened at 1031 hours. 1.2.1.3. PatC: I show the pre-meeting information in document 07/0600 on the screen including our agenda. I’d like to remind you to register your attendance.

1.3. Process

1.3.1. Review of Patent Policy 1.3.1.1. DorothyS: I would like to read the patent policy shown on the screen from the document (embedded in document 07/600) [reads all 5 slides]. Are there any questions on the policy? None. Does anyone know of any patents that the chair should be advised of at this time? Yes. 1.3.1.2. Sanjiv Nanda: Statement from Qualcomm. 1.3.1.3. “QUALCOMM may have intellectual property underlying a contribution that, if adopted, could be essential to the practice of the standard. If we do, we will timely comply with all provisions of the IEEE IPR policy.” 1.3.1.4. Dorothy: Are there any other advisories? No.

1.3.2. Review of Affiliations 1.3.2.1. On the IEEE web site there are instructions on disclosure of affiliation. [shows on screen]. I call your attention to two items in particular. #7 Whenever asked to do so, one must announce your affiliation. #11 In the event not disclosed you will lose certain rights. 1.3.2.2. Dorothy Stanley - Aruba Networks 1.3.2.3. Bob Miller - AT&T Labs Research 1.3.2.4. Emily Qi - Intel Corporation 1.3.2.5. The first time you speak, you should announce your affiliation. I cannot give legal advice. Consult your company’s legal counsel. Any questions? No.

1.3.3. Policies and Procedures 1.3.3.1. Dorothy: I suggest you review the ethics, policies/procedures, etc. on the web site.

1.3.4. Agenda Review 1.3.4.1. Dorothy: I show the agenda in 07/0600r2. Presentations are shown. 1.3.4.2. Emily: Remove Wake on LAN from Tuesday. 1.3.4.3. AllanT: I’d like to submit BSS Idle Time, documents 07/0687 and 07/0688 1.3.4.4. Dorothy: Any further changes? 1.3.4.5. Emily: I’d like to add Motions on Draft 0.12

Submission page 2 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

1.3.4.6. Dorothy: Any further? No. Is there anyone who might make a motion to adopt the agenda as shown? 1.3.4.7.

1.3.4.8. 1.3.4.9. 1.3.4.10. Move to adopt the agenda in 11-07-0600-02-000v-may-agenda. 1.3.4.11. Moved: Emily Qi 1.3.4.12. Second: Allan Thomson 1.3.4.13. Dorothy: Is there any objection to approving the motion unanimously? None. So moved an approved. 1.3.4.14. Result: Unanimous.

1.3.5. Status and Objectives for Meeting 1.3.5.1. Dorothy: Thanks to Emily for converting the document to the IEEE format, and Bill Marshall for his help. The only remaining comments are in 07/594.

1.3.6. Approval of Minutes 1.3.6.1. Dorothy: We have two sets of meeting minutes to approve. We have corrected Qi’s noted errors and these have been uploaded as r3. 1.3.6.2. [Secretarial Note: Qi was mistakenly identified as the presenter on two contributions. The presenter attribution is corrected in r3] 1.3.6.3. Move to approve the meeting minutes in 11-07-0361-03-000v-minutes-tgv- orlando-meeting-mar-07.doc. 1.3.6.4. Moved: Emily Qi 1.3.6.5. Second: Allan Thomson (Cisco Systems) 1.3.6.6. Any objection to approving unanimously? None. 1.3.6.7. Result: Unanimous. 1.3.6.8. Move to approve the meeting minutes in 11-07-0599-00-000v- teleconference-meeting-minutes-may-3-2007. 1.3.6.9. Mover: Allan Thomson 1.3.6.10. Second: Sanjiv Nanda. 1.3.6.11. Result Unanimous.

1.3.7. Presentation of Document 07/0642r0 1.3.7.1. Menzo Wentink (Conexant) presented document 07/642r0 on TIM Broadcast. The presentation seeks to provide a mechanism to receive the TIM field with

minimum overhead vis-à-vis probe requests. The contribution advocates addition of a new action frame and IE. TIM Broadcast adds a small overhead per beacon period. Normative text may be found in document 07/671r0. 1.3.7.2. Brian Hart (Cisco): Questions regarding timing, etc. 1.3.7.3. Menzo: [Discussion on detail] 1.3.7.4. Manoj Despande(Qualcomm): You have to listen for TIM, etc? 1.3.7.5. Menzo: You don’t actually have to, since you are already listening. This takes the TIM out of the beacon. 1.3.7.6. JoeKwak(: The format seems to imply that you might send 8 TIMs/beacon period, one for each rate? 1.3.7.7. Menzo: Just two. One at lowest rate, and a second at OFDM rate. 1.3.7.8. JoeK: Why does the format allow you to send a TIM for each rate? Why are there “n” occurrences? 1.3.7.9. Menzo: You could have a number of them. I limit the text to two, but you could have more. 1.3.7.10. JoeK: The upper limit is number of OFDM rates +1? 1.3.7.11. Menzo: Actually it could be any number. 1.3.7.12. JoeK: Why format it as “n” if there are only two? 1.3.7.13. Menzo: Might want to have three. 1.3.7.14. AllanT: Why do you want this to be mandatory? 1.3.7.15. Menzo: Addresses power saving. 1.3.7.16. AllanT: The issue of transmitting at various rates. The rate of a station may change while sleeping. Under what circumstances would a station not have to read the beacon? So you must always transmit at least at the beacon rate? 1.3.7.17. Menzo Yes. 1.3.7.18. Allan: So there is always a beacon and a TIM Broadcast? 1.3.7.19. Menzo: Yes. I am not saying you should not listen to the beacon anymore. 1.3.7.20. QiWang (Broadcom): This scheme seeks to separate information from the beacon. Won’t we be transmitting a lot of mini-beacons if others extract info and transmit it separately? Also, why can’t this be handled by a PS-Poll? 1.3.7.21. Menzo: This separates the information that a STA needs most frequently. Extracting other information would create more IEs, etc. So this would be a special case. I don’t think there should be other mini-beacons. PS-poll requires transmission and turn-around, much like probe response. 1.3.7.22. Moo Ryong Jeong (DoCoMo):How to you guarantee the timing of the transmissions? 1.3.7.23. Menzo: There is the same problem with the beacon. TBTT is not protected. 1.3.7.24. Moo Ryong Jeong: What is the implication of client behavior? You must listen to beacon and also this? Doesn’t that mean the STA has to stay awake for both? 1.3.7.25. Menzo: No. 1.3.7.26. Moo Ryong Jeong: There are a lot of other parameters in the beacon, such as time stamp. How is this information kept coherent? How do you guarantee that the station going back to active mode will adhere? 1.3.7.27. Menzo: You must still listen to the beacon, just listen less with this. 1.3.7.28. Emily Qi (Intel): TIM broadcast offset appears coupled to number “n”. Is that necessary?. 1.3.7.29. Menzo: There are only two, and these frames save time.

1.3.7.30. Emily: On power saving, will these treated as regular broadcast frame? There is a primitive missing from the association response. Is your overhead calculation valid for “b”? 1.3.7.31. Menzo: 588 uSec for two frames. 1.3.7.32. Emily: But this is action frames, what about back-off, etc. 1.3.7.33. Menzo: Would you be more supportive if optional? 1.3.7.34. Dorothy: Let’s close questions and have a straw poll to preserve our schedule. 1.3.7.35. Keith Amann (Polycomm): You’ve made the claim that you don’t have to listen to every beacon. If you add these frames, it seems that you add back any airtime that you may have saved. 1.3.7.36. Menzo: Don’t have to listen to every TIM frame: Rather than listening to beacons, you listen to these frames. 1.3.7.37. Keith: What problem are you trying to solve for the station? 1.3.7.38. Menzo: Reduces the time it must stay awake. 1.3.7.39. Keith: You are trying to give the station something else listen to with a shorter receive window. 1.3.7.40. Menzo: I’d be OK with doing it every DTIM instead. 1.3.7.41. SanjivN: I support doing this every DTIM. The numbers you show seem not to take into account the collateral. 1.3.7.42. Dorothy: We have to move along. 1.3.7.43. BobO (Cisco Systems): You are not saying is that when the station hibernates this allows that station look with the same periodicity that it would have used with beacons, it now looks for TIMs. It would seem that this is a minimum improvement. 1.3.7.44. Menzo: You have to add wake-up time, etc. 1.3.7.45. BobO: Even if you get 100% efficiency out of this it seems like only a 5% improvement. 1.3.7.46. Menzo: Add slack time to beacon: 2 ms. Add the same slack time to the TIM. You go from 2000 to about 400 uSec. You double the battery life. 1.3.7.47. Dorothy: Out of time. Do you want a straw poll? Yes, Mandatory and Optional. 1.3.7.48. Straw poll: 1.3.7.49. I might support (a) TIM Broadcast Mandatory or (b) TIM Broadcast Optional. 1.3.7.50. Mandatory: Yes 6, No 16 1.3.7.51. Optional: Yes 15, No 6

1.3.8. Presentation of Document 07/0667r0 1.3.8.1. Allan Thomson (Cisco Systems) presented document 07/667r0 on E-911 Bits. The contribution aims to improve operation of E-911 operation, building on member feedback on using four alternative approaches. Straw polls in last session suggested option 3 as most-favored. This solution is to add two new bits to the Wireless Network Management Capabilities field: Bit7: E911 CIVIC Location, and Bit8: E911 GEO Location. Normative text in 07/298r1 covers these additions. 1.3.8.2. QiWang: You are not suggesting implementation of a particular one. Clients will have to implement both. There is much concern about overloading clients with more capabilities. 1.3.8.3. Allan: We may end up with a recommended format. Would there ever be a circumstance where one would be preferred over another? It is new in the standards body.

1.3.8.4. SteveMcCann (Siemens): I speak in favor, since one of the TGu requirements is to provide a means of E911. We have been talking to IETF and others, and there seems to be a number of formats (reference in addition to two mentioned here). The idea is the network would do the conversion. The specific format is going to be determined by the regulatory regime. 1.3.8.5. EmilyQi: Is this feature intended to let the AP identify what format it is following. The stations have their own options. 1.3.8.6. DaveStephenson (Cisco): The station may not have to interpret. Does that help? 1.3.8.7. QiWang: I don’t object to this proposal. But is it possible that AP1 and AP2 could do orthogonal methods? 1.3.8.8. Allan: There may be situations where a CIVIC address doesn’t apply. For example in a harbor, a CIVIC address may be irrelevant. Both may be required. 1.3.8.9. RogerDurand (RIM): There are areas that will require both. 1.3.8.10. Move to incorporate normative text from 11-07-0298r1-000v-normative-text- presence-e911-clarification.doc into the TGv draft. 1.3.8.11. Moved: Allan Thomson 1.3.8.12. Second: Brian Hart 1.3.8.13. For 21, Against 0, Abstain 5. The motion passes.

1.3.9. Discussion of Comment Resolutions 1.3.9.1. Emily Qi presented document 07/594r3 discussing comment resolutions. There are about 280 comments on draft 0.10. I have incorporated about 150 editorial comments and about 100 technical comments. I am seeking volunteers to work on remaining technical comments. [reviews categories] 1.3.9.2. Allan: You’d like volunteers now? 1.3.9.3. Dorothy: Yes. 1.3.9.4. Allan: Volunteers for presence and FBMS 1.3.9.5. Emily: BSS Transition Mgmt? None. 1.3.9.6. Diagnostics? None. 1.3.9.7. Extended Channel Switch Announcement? 1.3.9.8. Dorothy: Will cover in session. 1.3.9.9. PeterEcclesine: TGy will cover this on Tuesday evening, as well as couplings to “n”. 1.3.9.10. Dorothy/Emily go down list and note volunteers. 1.3.9.11. Dorothy: There are some other problems that have to be addressed. The number of IEs is becoming too large. We have to consider moving certain IEs to other areas if it doesn’t impact functionality.

1.4. Closing

1.4.1. Recess 1.4.1.1. Dorothy: We have reached the end of our time this session and our agenda. We shall meet Tuesday morning. We have some presentations, and then we will move to incorporate. 1.4.1.2. QiWang: Can you tell the us the rev number of the agenda document? 1.4.1.3. Dorothy: Version 3 will be uploaded. 1.4.1.4. Recess at 1229 hours.

2. Tuesday Morning Session, May 15, 2007 2.2.1.1.

2.3. Opening

2.3.1. Call to Order 2.3.1.1. DorothyS: I call the meeting to order. 2.3.1.2. Meeting convened at 0800 hours.

2.4. Process Dorothy: We have three presentations this session.

2.4.1. Presentation of Document 07/0086r3 2.4.1.1. Alex Ashley (NDS Ltd.) presented document 07/0086r3 on BSS AP Time Sharing. The contribution covers time sharing between APs in an interference-limited environment where frequency separation is not sufficient. The proposal was presented in a previous meeting, aimed at domestic environments. This presentation adds enterprise environment provisions. In a multiple dwelling unit environment, an algorithm is used to facilitate sharing between APs that are part of different networks. In the enterprise case, communication over the DS linking them is used. The method is aimed at situations where relatively few APs experience co-channel difficulties and would thus suffer lower throughputs and higher error rate. There are two new action frames to support the collaboration. A simulation was created to estimate what improvements can result from the tit-for-tat algorithm, as well as a description of when use of the technique would be beneficial. 2.4.1.2. Henry Ptasinski (Broadcom): What is the effect of defection? How do you know a defection has happened? How do you detect it? How can you tell a non-supporting AP from a defection? 2.4.1.3. Alex: You cannot keep non-supporting APs out of the network. If you are in EDCA mode waiting to get access to the channel and you see packets from a network that is not yours, you know you have interference. The feedback in the AP supporting the feature will reduce offers if they are not reciprocated. 2.4.1.4. HenryP: What does one AP look for, though? 2.4.1.5. Alex: It looks for no benefit. 2.4.1.6. QiWang: You try to visualize two APs. You use bandwidth as a cost metric. Describes a scenario where sharing may not work correctly. You are introducing a TDMA overlay of CSMA. 2.4.1.7. Alex: As the network load increases, the chances of overlapping are enhanced. In such a case, inefficiencies result. Reducing the tendency of these overlaps produces more non-interfering time. 2.4.1.8. Qi: You also reduce the throughput of each AP. 2.4.1.9. Alex: When lightly loaded, you get the same result as without the sharing. At heavier loads you do better. 2.4.1.10. Dorothy: Let’s move to the next person. 2.4.1.11. AllanThomson: When would an AP know what was the right time to invoke the offer process. If you are in a home, when would you do this? It will impact the throughput through the AP. What is the criterion for starting the process? 2.4.1.12. Alex: If the network is lightly loaded, there is little point, but also no penalty. 2.4.1.13. Allan: So when the throughput gets high, that is when you begin the process?

2.4.1.14. Alex: Yes, it is up to manufacturers how to implement it. 2.4.1.15. SolomonCainin (Intel): There is an assumption that you have to collaborate. Why? If you just share the medium everything should be OK. How do you detect that you need to share? 2.4.1.16. Alex: There are not enough channels in available 802.11 spectrum to arrange a reuse pattern without overlap. You could look at delays in getting the channel, e.g., having to be silent. You know when the channel is busy. 2.4.1.17. FloydBackes (Autocell): You could base the decision to offer on detection of rogues and other traffic. You could take a conservative approach and offer only when the other station could collaborate. 2.4.1.18. Dorothy: Let’s move to the motion… 2.4.1.19. Move to incorporate normative text from 11-07-0084-02-000v-access-point- collaboration-enhancing-qos-and-spectrum-efficiency.doc into the TGv draft. 2.4.1.20. Moved: Alex Ashley 2.4.1.21. Seconded: Bob Miller 2.4.1.22. For 10, Against 12, Abstain 5. The motion fails.

2.4.2. Presentation of Document 07/0695r0 2.4.2.1. Floyd Backes (Autocell) presented document 07/0695r0 on Multi-Level Power Control. Companion normative text can be found in 07/465r2. This contribution has been previously presented, and will discuss simulations and results. The transmit power control presented here is different than that for regulatory control, and is designed to improve network performance. A simple example is given showing behavior of overlapping, interfering cells. If you control power of the AP only you get some PER improvement, which Is increased further by controlling STA power. But if you reduce the power of the access point, you can produce a coverage “holes” because beacons will not be heard over the larger range afforded at high power. Multi-level control differentiates power of data from that of beacons and other control-plane messages to minimize the effect. The recommended approach is to include a Relative Power Limit Request IE to be carried in beacons, association responses, reassociation responses, probes and Relative Power Limit Response Frames. The request can operate on as few as one STA, or as many as all in a BSS. 2.4.2.2. SanjivNanda (Qualcomm): What about control frames? Are they covered? 2.4.2.3. Floyd: Control frames go out the same as data. 2.4.2.4. Myles: Power constraints apply to STA only, but not to AP in some bands. 2.4.2.5. Floyd: 5 GHz band has power constraints. 2.4.2.6. Myles: Why can’t this mechanism be used? 2.4.2.7. Floyd: Maybe it could. 2.4.2.8. Myles: What happens if you decrease the power and then increase it to get to an outlying station? If you take into account the behavior of the stations, there could be a problem. 2.4.2.9. Floyd: No algorithms described, but possible to do. 2.4.2.10. HenryPtasinski: Control frames would be power controlled? 2.4.2.11. Floyd: Control frames would go out with data. 2.4.2.12. SudheerMatta: Legacy stations could be very confused. 2.4.2.13. Jason (Broadcom): On the simulation the error rate for three cases: 22% vs. 18%. What rates were used? What sort of change in S/N did you get, and what was the power change? 2.4.2.14. Floyd: 54 Mbps, 1-2 Mbps video streams. Alex Ashley contributed the simulator, so perhaps he could comment…

2.4.2.15. Alex: It would be straightforward to determine this, I would have to simulate one house. 2.4.2.16. SanjivNanda: The RTS/CTS is not covered. 2.4.2.17. Floyd: Currently the max power by receiving station is for MPDUs. This does cover control frames. I believe I mis-spoke earlier. 2.4.2.18. Jason Trachewsky (Broadcom): The protocol allows operation over a large range. What sort of range in output power was defined? 2.4.2.19. Floyd: About 10dB. 2.4.2.20. Jason: Many implementations would have difficulty with this range of control. 2.4.2.21. Move to incorporate normative text from 11-07-465r2-000v-multi-level-power- control.doc into the TGv draft. 2.4.2.22. Mover: Floyd Backes 2.4.2.23. Seconder: Bob Miller 2.4.2.24. Dorothy: Voting members only, please. 2.4.2.25. For 14, Against 11, Abstain 10. The motion fails.

2.4.3. Presentation of Document 07/0737r0 2.4.3.1. Matt Smith (Atheros) presented document 07/0737r0 on behalf of Kevin Hayes and other authors covering Sleep Mode with AP Filtering. Aggressive power management requires long sleep periods. This presentation is similar to Wake-on-LAN. Previous WoL presentations have treated filtering client packets by various means and triggering clients by various special patterns. Dynamic security can be an issue, however, because the client has to participate in key exchanges, etc. Any update to key material requires OS participation in the client, not just “minimal awareness”. Ways infrastructure could help is with traffic filtering and sleep mode support. Advantages are claimed to be greater power savings, simplification of sleep-mode security state maintenance, and economies with airtime of frames that would be dropped by the client if asleep. An outline of the protocol that establishes the sleep mode and sets up the filtering was provided with sequence diagrams. A security model was also presented. Aim is to create normative text for next meeting. 2.4.3.2. Questions? 2.4.3.3. SanjivNanda (Qualcomm): Looking at trigger frames. Do these follow the TIMs? 2.4.3.4. Matt: Yes, didn’t cover that. Association is never lost. 2.4.3.5. Sanjiv: Why is reassociation included? 2.4.3.6. Matt: If an STA chooses not to participate in key association, it will have to reassociate. 2.4.3.7. Sanjiv: AP sends broadcast material? 2.4.3.8. Matt: Yes ARP, etc. 2.4.3.9. MandyPeng (Infineon – Taiwan): How do we deal with keys if there is a failure. There is a 50 second timeout, then it must reassociate. How does the access point notify the STA that it has been disassociated? 2.4.3.10. Henry: The requirement that the AP de-ops everyone and revokes keys. No draft text yet. A possibility is that we relax the reassociation requirement. The reassociation message could be used to handle this (to get fresh keys). 2.4.3.11. JoeKwak: On slide 14. Sleep mode wakeup frame. This is actually not sleep wakeup but rather notification, right? 2.4.3.12. Matt: Yes. Non filter-matching frames don’t get delivered. 2.4.3.13. JoeK: You would have to wake up every DTIM? 2.4.3.14. Matt: You already have a filter, so you don’t have to.

2.4.3.15. JariJokela(Nokia): How is the sleep interval negotiated? 2.4.3.16. Matt: We think by an additional field. IE or management access frame. 2.4.3.17. Henry: Now there is a listen interval upon association. Also as part of sleep process, an interval could be specified. 2.4.3.18. Jari: What is function of the trigger frame after the sleep mode wakeup. 2.4.3.19. Henry Ptasinski(Broadcom): It responds to what the previous data frame was. 2.4.3.20. Jari: What would be the effect of a unicast Wake-on-LAN frame? 2.4.3.21. Matt. Any NETBIOS, WoL, or matching packet would cause a trigger. 2.4.3.22. RogerDurand(RIM): I support what you’ve outlined. I’d like to participate. I have some concerns regarding scaling. Could a profile be produced? 2.4.3.23. SudheerMatta (Trapeze networks). Clients routinely walk away. We would have to negotiate keep-alives. Let’s say 10 clients, how do we handle them as they wake up and need key refresh? If the trigger frame were broadcast, a client might not be able to decrypt. How is the trigger frame encrypted? 2.4.3.24. Henry: Each trigger is encrypted, so the filter must match the encryption. 2.4.3.25. Matt: Yes. 2.4.3.26. Henry: GPK refresh could have to be refreshed very often. PTK much less so. Is there a way to differentiate the refreshes? 2.4.3.27. MooRyongJeong: I’d like to support this proposal. Unicast packets will be dropped. If trigger frame is multicast, how is that handled if only delivered at DTIM. 2.4.3.28. Matt. May not get that frame. 2.4.3.29. [discussion regarding QoS implications] 2.4.3.30. Khong Neng Choong (BT Multimedia) [suggestions on alternative mechanisms for not dropping frames] 2.4.3.31. Henry: Stations don’t see broadcast messages. Today such frames don’t get delivered in a WoL scenario. 2.4.3.32. Dorothy: We are out of time. The next session is tonight at 1930. BSS Idle Time will be presented, as well as a motion to adopt draft 0.12. I’d like to thank those working on comment resolutions.

2.5. Closing

2.5.1. Recess 2.5.1.1. Dorothy: We have reached the end of our time this session and our agenda. We shall meet Tuesday evening. We are recessed. 2.5.1.2. Recess at 0957 hours.

3. Tuesday Evening Session, May 15, 2007 3.2.1.1.

3.3. Opening

3.3.1. Call to Order 3.3.1.1. DorothyS: I call the meeting to order. 3.3.1.2. Meeting convened at 1930 hours.

3.4. Process Dorothy: We have a presentation. 3.4.1.1.

3.4.2. Presentation of Document 07/0688r0 3.4.2.1. Allan Thomson (Cisco) presented document 07/0688r0 BSS Max Idle Time Advertisement. Companion normative text can be found in document 07/687r0. The contribution addresses the problem caused by STAs not knowing how long they can be in sleep mode. A mechanism to advertise the maximum time period is proposed, with IE. There are two fields: Max Idle period, and Idle Options. Idle options allow keep-alives to be protected or not (even if RSNA is deployed). 3.4.2.2. Brian Hodges (Cisco): Is there a guarantee you won’t be disconnected? 3.4.2.3. Allan: No. Just a recommendation. 3.4.2.4. Jari Jokela (Nokia): What frames are involved? 3.4.2.5. Allan: Any frame, management action frame, etc. 3.4.2.6. Henry: The special frames we talked about are the TGw frames. 3.4.2.7. Move to incorporate normative text from 11-07-0687-00-000v-bss-max- idletime.doc into the TGv draft. 3.4.2.8. Mover: Allan Thomson 3.4.2.9. Seconder: Henry Ptasinski 3.4.2.10. For 12, Against 0, Abstain 7. The motion passes.

3.4.3. Adoption of TGv draft 3.4.3.1. Emily: I’d like to get the new draft approved. 3.4.3.2. Move to adopt TGv Draft 0.12 as the TGv draft, 3.4.3.3. Mover: Bob O’Hara 3.4.3.4. Seconder: Emily Qi 3.4.3.5. For 14, Against 0, Abstain 5. The motion passes.

3.4.4. Addition to Agenda for Next Session 3.4.4.1. Dorothy: I had a request from Menzo to add a presentation in a slot. Is there anyone who would make this motion. Seeing no one, then that will not happen.

3.4.5. Comment Resolution 3.4.5.1. Dorothy: Comment resolutions have been in progress. Let’s begin with BSS Transition. Could we have a review on progress?

3.4.6. Comment Resolutions 3.4.6.1. Emily Qi (Intel) presented the comment spreadsheet, document 07/0738r0, isolating and discussion lines corresponding to individual comments for which resolutions have been crafted. [Secretarial Note: The following represents highlights of the discourse, and is not exhaustive. Consult the document for the comment numbers, comments, dispositions and recommended resolutions.] 3.4.6.2. Line 167. Counter. Remove sub-clause 7.3.2.27.1 and 2 text and titles for 7.3.2.28.4,5,and 6. 3.4.6.3. Line 168. Counter. No change to text. The BSS available admission capacity element field contains a BSS available admission capacity element IE. Lines 169 and 170 treat similar issues. Submission page 11 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

3.4.6.4. Line 269. Accepted. 3.4.6.5. Line 273. Frame Format. Counter. Change “STA” to “AP STA”. 3.4.6.6. Line 275. Counter. Change “expiration time” to “validity interval”. 3.4.6.7. Line 276. Counter. Change "A STA shall include the result of its BSS transition decision in the Target BSSID field in the BSS Transition Management Response frame." to "A STA shall include the result of its BSS transition decision in the Target BSSID field or Status Code field in the BSS Transition Management". 3.4.6.8. Line 280. Counter. Same as CID#61. Also, Line 281 similarly. 3.4.6.9. Emily: That concludes the comment resolutions. 3.4.6.10. Move to adopt the comment resolutions in 11-07-0738-00-000v-tgv-d0-10- validation-review-comments-bss-transition-management and incorporate the indicated text changes into the TGv Draft 0.12. 3.4.6.11. Mover: Emily Qi 3.4.6.12. Seconder: Bob O’Hara 3.4.6.13. For 11, Against 0, Abstain 8. The motion passes. 3.4.6.14. Dorothy: Next we have Diagnostics. 3.4.6.15. Emily: I shall handle Diagnostics from the same spreadsheet. 3.4.6.16. Line 152. Counter. Change the field “Status” to “Diagnostic Status” throughout the section. Change the field “Status: to “Event Status” throughout the section 7.3.2.51. 3.4.6.17. Alex: In the Event Status, there was an identical comment regarding confusion with the same term being used in two places. We need to make sure we resolve both comments the same way. 3.4.6.18. Emily: 3.4.6.19. Line 152. Counter. Change the field “Status” to “Diagnostic Status” throughout the section. Change the field “Status” to “Event Status” throughout section 7.3.2.51. 3.4.6.20. Line 153. Rejected. 3.4.6.21. Line 184. Counter. Same as CID #101 and #104. 3.4.6.22. Line 192. Deferred. Line 174 covers the same problem. Change 6 level headings to a list starting with lower case “a”. 3.4.6.23. Line 186. Reject. See 7.3.2.52.4 for the defined format. 3.4.6.24. Line 187. Counter. Add PSMP with the value “6” and change the reserved value to “7” to “255”. 3.4.6.25. Line 188. Counter. Rename to “Result Code” throughout the section 7.3.2.52. 3.4.6.26. Line 189. Counter. Remove STA Report Group Type from table V16. 3.4.6.27. Line 190. Counter. See 11-07-0474r0. 3.4.6.28. Line 191. Deferred. Might be added after moving 7.3.2.54 to 7.4.8. 3.4.6.29. Line 192. Deferred. Same response. 3.4.6.30. Line 227. Counter. Change “go back to the requesting AP and 802.11 authenticate…so that it can respond” with “respond to the requesting AP”. 3.4.6.31. Line 238. Counter. P151, L35. Change “the Multicast MAC Address and trigger conditions for diagnostic reporting shall be specified in the request” to “For triggered Multicast Diagnostic reporting the Multicast MAC Address and trigger conditions for diagnostic reporting shall be specified in the request”. 3.4.6.32. Line 243. Accepted. Change to 8 octets. 3.4.6.33. Line 260. Reject. Two normal power saving modes indicate whether the STAs wake up to receive DTIMs or not. 3.4.6.34. Emily: I’d like the group to approve these comment resolutions…

3.4.6.35. Move to adopt the comment resolutions in 11-07-0736-00-000v-comment- resolutions-tgv –d0-10-validation-review-comments-diagnostics and incorporate the indicated text changes, except for CID #108 and #190 into the TGv Draft 0.12. 3.4.6.36. Mover: Emily Qi 3.4.6.37. Seconder: Allan Thomson 3.4.6.38. For 12, Against 0, Abstain 5. The motion passes. 3.4.6.39. Dorothy: Events next. 3.4.6.40. Alex Ashley (NDS Ltd.) reviewed comments related to the “Events” category from spreadsheet document 07/736r0. 3.4.6.41. Line 2. Counter. Looking at the 2007 baseline, IEs such as “Measurement Request Element” use terms such as “”Management Type definitions for measurement reports: Suggest resolution is “Event Type definitions to event requests and reports” 3.4.6.42. Line 3. Accept. 3.4.6.43. Line 4. Defer. [Discussion between Emily and Alex on how to handle]. 3.4.6.44. Dorothy: We have two options: add text, or make both cross-ref’d the same. We’ll call out this one as unaddressed. 3.4.6.45. Line 5. Accept. Add “milliseconds” to the end of the definition. 3.4.6.46. Line 6. Accept. Suggest changing to “The Authentication Type field contains one of the AKM suite selectors defined in table 34” 3.4.6.47. Line 7. Counter. The table should be removed and use table v5 (Event type definition). 3.4.6.48. Line 8. Accept. Using Table 23 would seem to be sensible, but “3 – Incapable” is not in Table 23. For this reason suggest using the “Result Code” option. 3.4.6.49. Allan: Shouldn’t we understand which one we want to accept? Are we ever going to use Table 23? 3.4.6.50. Alex: We should reflect the convention in the baseline. 3.4.6.51. Allan: Let’s look at table 23. 3.4.6.52. Alex: Table 23 is two pages of status codes. 3.4.6.53. [Discussion] 3.4.6.54. Dorothy: Perhaps we should exclude this for now. 3.4.6.55. Line 9 (84). Accept. 3.4.6.56. Line 10. Decline: According to the existing definition, no-ack frames would not be used as past of the transition time calculation. It is not possible to use non-ack frames in this calculation as there is no way to know if these frames were received by the source and destination BSS. 3.4.6.57. Allan: Suggest we put in a sentence to that effect. Will this comment come back otherwise? 3.4.6.58. Alex: You prefer to add an explanation? 3.4.6.59. Allan: Yes. 3.4.6.60. Alex: OK 3.4.6.61. Line 11. Accept. Change “present” to “valid”. 3.4.6.62. Line 12. Accept. 3.4.6.63. Line 13. Decline. The “Target BSS RSNA” and “Target BSSID” sub- elements have the same structure, but they have different identifiers because they are used in requests to specify the requested information. 3.4.6.64. Line 14. Declined. “Event Requests that do not include alerting conditions” are preserved on a transition within an ESS. 3.4.6.65. Jiyoung Huh (LG Electronics): What does the event mean?

3.4.6.66. Alex: If you have a pending request, you can have conditions that cause and alert. If it is not one of these, then you should cancel it. (Alex’s interpretation). 3.4.6.67. Jiyoung: Does an outstanding event include an alerting condition? I believe an outstanding event includes the alerting conditions. 3.4.6.68. Dorothy: Are you asking if the alerting conditions are part of the event? 3.4.6.69. Emily: Not outstanding events, rather outstanding event requests… 3.4.6.70. Jiyoung: If so, the outstanding events may not include the trigger conditions. On page 142 this is discussed. 3.4.6.71. Alex: It doesn’t seem ambiguous to me. 3.4.6.72. Emily: My interpretation is that all outstanding requests remain except in a new BSS. 3.4.6.73. Dorothy: Suggest we take off line. 3.4.6.74. Line 15. Accept. 3.4.6.75. Line 16. Defer. Looking at 7.3.2.50, sub-elements are including in the event request frame. 3.4.6.76. Jiyoung: [reads draft to clarify comment, page 141] 3.4.6.77. Emily: I agree with Jiyoung’s point. It should be zero or more transitions. 3.4.6.78. Alex: We will pull for now, but we will add clarifying text. We’ve already covered the next two, because they are identical to two previously done. That concludes the comment resolutions… 3.4.6.79. Move to adopt the comment resolutions in 11-07-0728-00-000v-tgv-draft-0- 10-validation-review-comments-event-category except for CID #78, #83, #84, #85, #224, and #226 and incorporate the indicated text changes into TGv Draft 0.12. 3.4.6.80. Mover: Alex Ashley 3.4.6.81. Seconder: Emily Qi 3.4.6.82. For 9, Against 0, Abstain 4. The motion passes. 3.4.6.83. Dorothy: Next is FBMS 3.4.6.84. Allan Thomson presented resolutions in 07/0717r0… 3.4.6.85. Line 214. Accepted. Remove section headers. 3.4.6.86. Line 215. Duplicate. 3.4.6.87. Line 216 Declined. Described adequately. 3.4.6.88. Line 245. Declined. The response will be transmitted as a unicast frame to all subscribed STAs and therefore if the STA is asleep the TIM bit will be set and the STA will pick up the frame the next time the STA polls for its queued traffic. 3.4.6.89. Bob O’Hara: Are you sure you’ve covered it all? 3.4.6.90. Allan: You’re right, we should look again just for sure. [examines draft] 3.4.6.91. Line 255. Change as shown. 3.4.6.92. Line 256. Change as shown to clarify. 3.4.6.93. Bob O’Hara: How does this relate to “n”? Backward compatible? 11n has specified something different than previously done. 3.4.6.94. Allan: Good point. However, this would require a global change on the entire document. 3.4.6.95. OHara: Just asking the question. Let’s keep “on our radar”. 3.4.6.96. Dorothy: We could pull this one out, or we could adopt and take an action item. 3.4.6.97. Allan: I’d be willing to take an action item on this one. 3.4.6.98. BobO: We should be aware “n” might make a comment during letter ballot.

3.4.6.99. Line 257. Same comment. Resolve same way. 3.4.6.100. Line 275. “Change AID 0 Descriptor” to “FBMS Descriptor”. 3.4.6.101. Move to adopt the comment resolutions in 11-07-0717-00-000v-tgv-draft-0- 10-fbms.xls except for CID #229 and incorporate the indicated text changes into the TGv Draft 0.12. 3.4.6.102. Mover: Allan Thomson 3.4.6.103. Seconder: Emily Qi 3.4.6.104. For 8, Against 0 , Abstain 2. The motion passes. 3.4.6.105. We have about 4 minutes left, and I don’t think it would be worth starting another group. 3.4.6.106. Allan: The exceptions we removed---when will we act on these? 3.4.6.107. Dorothy: The next times we meet are Wed 1330-1530. We have some time on Thursday 1330-1530 as well. We could fit your comment in. 3.4.6.108. Dorothy: Menzo, do you want to add your presentation? 3.4.6.109. Menzo: Yes I wish to so move… 3.4.6.110. Amend the TGv May agenda, adding a “TIM Broadcast (30) presentation following the “Regulatory Class” presentation. 3.4.6.111. Moved: Menzo Wentink 3.4.6.112. Seconded: Jari Jokela 3.4.6.113. Result Unanimous.

3.5. Closing

3.5.1. Recess 3.5.1.1. Any objection to recessing? None. Very well, we are recessed. 3.5.1.2. Recess at 2130 hours.

4. Wednesday Afternoon Session, May 16, 2006

4.2. Opening

4.2.1. Call to order 4.2.1.1. Dorothy: I call the meeting to order. 4.2.1.2. Meeting convened at 1330 hours.

4.3. Process

4.3.1. Presentation of Document 07/394r4 4.3.1.1. Jari Jokela (Nokia) presented document 07/398r4 on Dedicated Protection. This presentation was given previously and improvements have been made. The presentation observes that many radio services operate in adjacent, harmonically-related, or overlapping bands. It is becoming difficult to combine multiple services in such a way that they do not interact, particularly using a common antenna. Moreover, scheduling access to the common antenna engenders more difficulties. The contribution recommends a method that can be used to ensure an AP will not send unicast packets during a specified period that corresponds to an interval when another radio will be using the antenna or interference would be experienced. The outlined method is claimed simpler and more practical than use of power save or CTS-to-self methods for accomplishing the intent. The dedicated protection Submission page 15 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

mechanism and how it may be used are also covered. Use of the technique with mesh architectures/protocols is also discussed. 4.3.1.2. BobMiller (AT&T): OK if a phone wants to cut its throughput, but what happens if a large number of phones request protected access from an AP at once? Doesn’t this cut the throughput for the entire AP, or at least create a difficult scheduling problem? Does it also seem that the lower-throughput service is modulating the effectiveness of the high-throughput service, perhaps having the “tail wag the dog”. 4.3.1.3. Jari: Yes, I agree. 4.3.1.4. Emily: Thank you for the presentation. I believe this is something that should be considered. Why don’t you use an action frame instead of the framework you have outlined? 4.3.1.5. Allan: On slide 3, the slide would seem to indicate that it would be simpler to use 802.11a. 4.3.1.6. Jari: Yes, that would be a solution, however it ignores harmonics. 4.3.1.7. Allan: This really has to work with “n”. Has an analysis been done for this amendment? 4.3.1.8. Jari: No. 4.3.1.9. BobO’Hara: This makes major changes in how APs operate. You are now asking it to implement an arbitrary number of different TDMA overlays. In the slide claiming 100uSec to implement, I think the scheduling would make this extremely optimistic. 4.3.1.10. Jari: I agree there are implementation challenges. Using CTS-to-self is also not very optimal. This tries to be more intelligent than that, at least. 4.3.1.11. RogerDurand(RIM): I am concerned that Bluetooth profiles for Hi-Fi stereo would seem to indicate they are active virtually all the time. In that scenario the AP would be “held off” for a very long period. I think it may not be practical from the AP side. Whatever QoS mechanisms are already in play, this would materially impact them. I think this solution may be worse than the disease. 4.3.1.12. JouniMalinen (Devicescape): I think this could have a big impact on “n”. 4.3.1.13. PeterEcclesine (Cisco): This is reminiscent of the RF lighting scheduling incompatibilities we considered a few years ago. Now we have Wi-MAX with its timing. And with this proposal, we now have timing from, say, a wireless mouse. 4.3.1.14. Dorothy: Would you like to have a straw poll? No.

4.3.2. Presentation of Document 07/0754r0 4.3.2.1. Peter Ecclesine (Cisco) presented 07/0754r0 on normative text changes involving Regulatory Classes in the TGv draft. The presentation outlines the details of regulatory classes including interpretations by equipment. The presentation examines normative text in TGv draft treating the regulatory topic. The presentation suggests that the editor be instructed to remove the qualifiers from regulatory domain descriptions to resolve any contradictions/misinterpretations. 4.3.2.2. QiWang (Broadcom) Is this the text that has been adopted in TGy? 4.3.2.3. Peter: No, not yet, but soon In order to stay coherent with other amendments, TGv will have to monitor other efforts to stay “in sync”. This document is trying to help that. 4.3.2.4. Qi: So this is correct as of now? 4.3.2.5. Peter: Yes, but only for the U.S. 3650 band. The TGy PAR is the only one open that can work on this. Right now this is the correct text for operating across all bands. 4.3.2.6. Qi: On the extension, that was “shipped” into TGy. Submission page 16 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

4.3.2.7. Peter: Yes, the answer was that we crafted language that would work for all bands. We did this in response to comments resulting from other bands/requirements. 4.3.2.8. Roger: I’m confused. On the bottom paragraph, you struck a portion. But up above you are apparently addressing the same thing. 4.3.2.9. Peter: The “above” is what TGy will look like after tomorrow. The insertions include the two qualifiers coming in tomorrow. The motion in “v” would be to remove the qualifiers. 4.3.2.10. Roger: The only difference is U.S. 3650? 4.3.2.11. Peter: Yes. 4.3.2.12. HenryP: Why is TGy putting it in when you recommend taking it our of “v”? 4.3.2.13. Peter: Covered previously. A comment mandated narrowing of TGy to only U.S. 3650 band. 4.3.2.14. Emily: This is the replacement change to 9.8.3, but some of the language appears elsewhere. 4.3.2.15. Peter: TGy will have modified the PICS, etc, so you won’t have to change it everywhere. It’ll already have been done. 4.3.2.16. Dorothy: The time to make the motion would be after TGy adopts? 4.3.2.17. Peter: That would be after AM tomorrow. See document 07/673r1.

4.3.3. Presentation of Document 07/0672r2 4.3.3.1. Menzo Wentink (Conexant) presented 07/0672r2 document on TIM Broadcast with changes to make the capability optional, and to suspend transmission of TIM frames if no client requests it. The TIM frames are now transmitted once per DTIM instead of once per beacon. At least one TIM must be transmitted per DTIM. A beacon check indication has been added to the TIM frame to indicate the client should inspect the next beacon. The normative text changes are outlined in companion document 07/671r2. The TIM beacon IE will be changed later to a capability bit per suggestion of Bob O’Hara. 4.3.3.2. HenryPtasinski: I don’t actually see any text that says “broadcast”. You also don’t say “no more than two”. Seems like it should be capped. 4.3.3.3. Menzo: What do you want as a cap? 4.3.3.4. Henry: Preferably one. 4.3.3.5. Bob Miller: What does optional mean? Implementation, or transmission of TIM broadcast? 4.3.3.6. Menzo: The AP doesn’t have to implement it. 4.3.3.7. Sudheer: I still don’t understand where the power savings come from. 4.3.3.8. Menzo: Pilots are transmitted at 10x beacon rate. The overhead of doing that is substantial. 4.3.3.9. Sudheer: Your calculation doesn’t consider backoffs. There is 500uSec per beacon. You also didn’t use aggregated beacons or Multiple BSSID cases. Nowhere in the text does it say when to wake up for this frame. At DTIM? How does the station know to wake up? 4.3.3.10. Menzo: There is a known offset from the TBTT. 4.3.3.11. Sudheer: The BC/MC comes after this frame? 4.3.3.12. Menzo: No. You could use Wake-on-LAN or choose to miss it. 4.3.3.13. Sudheer: After the beacon, you have a variable amount of BC/MC and then a TIM broadcast. The offsets will usually be wrong. Thus this may have to go right after the beacon. 4.3.3.14. Menzo: Could go right after the beacon, or between two beacons, for example. Could be right at TBTT if offset is zero. The station does know

when to receive it. I disagree that it does not produce power savings. [shows calculation]. This has a big impact on power consumption. 4.3.3.15. QiWang: The 36 microseconds needs to allow wake-up time. You prescribe 1 per DTIM. The AP already makes the best decision on transmission rate using whatever optimization it cares to use. Do you really have to send the same frame multiple times? I also fear this will be come a pattern for pulling info out of the beacon and sending it separately. 4.3.3.16. Menzo: You need a TIM the same rate as the beacon, which is usually 1 Mbps. A separate faster frame carries big economies over sending the same info in the beacon. I advocate sending a slow one and a fast one. 4.3.3.17. HenryP: On the overhead. Assume 1 TIM at 1 Mbps and another at 24 Mbps? No backoff considered? 4.3.3.18. Menzo: On the slide, we considered a beacon period of 1. A backoff doesn’t impact airtime as a SIFS would. 4.3.3.19. Roger: Menzo, I supported this and support it again. Once you are in the network and stationary it is a big power save help (more than half). 4.3.3.20. Moo Ryong: I support this as well. Any effort to reduce reception in the power save mode is worthwhile. The same technique was used in 1x to extract the same advantage. 4.3.3.21. Dorothy: You want to return tomorrow with changes? Yes. That ends the presentations. Let us proceed with comment resolution. We next consider the “General” Group. First however, Allan posted one comment in the FBMS group, #229 (line 245), now in 717r1. [shows text change on spreadsheet]. 4.3.3.22. Allan: The first inclination was to reject, but it was felt we should improve the spec. So have added new text to clarify. 4.3.3.23. Move to adopt the comment resolution on 11-07-0717-01-000v-tgv-draft-0- 10-fbms.xls for CID #229 and incorporate the indicated text changes into the TGv Draft 0.12. 4.3.3.24. Mover: Allan Thomson 4.3.3.25. Seconder: Roger Durand 4.3.3.26. For 14, Against 0, Abstain 4. The motion passes. 4.3.3.27. Emily: Comment #108 has changed. I’d like to make a motion. 4.3.3.28. Dorothy: What document? 4.3.3.29. Emily: 07/0736 4.3.3.30. Move to adopt the comment resolution for CID #108 in 11-07-0736-00-000v- comment-resolutions-tgv-d0-10-validation-review-comments-diagnostics and incorporate the indicated text changes into TGv Draft 0.12 4.3.3.31. Mover: Emily Qi 4.3.3.32. Seconder: Allan Thomson. 4.3.3.33. Dorothy: Any objection to adopting unanimously? None. 4.3.3.34. Adopted unanimously. 4.3.3.35. Emily: there is another for which I have prepared normative text. 4.3.3.36. Emily Qi presented CID #104 in Document 07/736. 07/0474r0 contains normative text prepared for #104. 4.3.3.37. Allan: You may also want to correct the “SID” in 7.3.2.65.4.21 to “SSID”. 4.3.3.38. Move to incorporate the text in 11-07-0474-00-000v-definition-for-ssid-sub- element-into TGv Draft 0.12 to resolve CID #104. 4.3.3.39. Mover: Emily Qi 4.3.3.40. Seconder: Sudheer Matta 4.3.3.41. Dorothy: Any objection to accepting unanimously? None. 4.3.3.42. Result: Unanimous.

4.3.3.43. Emily: Let’s begin with document 07/0735r1 for the “General” category. 4.3.3.44. Line 154. Deferred. 4.3.3.45. Line 155. Accepted. Remove 5.4.3.7 4.3.3.46. Line 156. Accepted. Remove 5.4.3.7 4.3.3.47. Line 163. Counter. Remove request report. 1. Remove Event Request/Report IEs, and Diagnostics Request/Report IE, and move the contents to the Event Request/Report frames and Diagnostics Request/Report frame. 2. Defer the FBMS and Multiple BSSID to the group discussion. For FBMS would like to defer to group. 4.3.3.48. Dorothy: Discussion? 4.3.3.49. Allan: The only disadvantage is if you want to use the capability somewhere else. We might be better to think about a list of useful IEs that we’d like to use across various applications. If you move it to a frame you’ll not be able to use it elsewhere. Does “n” or “r” have a similar problem and how did they solve it. 4.3.3.50. Bill Marshall (AT&T): “r” was chastised for using too many at 7. Somewhere around four seemed good. In between a possibility. 4.3.3.51. Straw poll: 4.3.3.52. Event Request and Event Response elements should move to the Action Frame. 4.3.3.53. Yes No. 4.3.3.54. Allan: Moving to a frame also eliminates IE? 4.3.3.55. Emily: If moved to frame then is not IE. 4.3.3.56. JoeK: IE moved inside frame does not require an IE ID. 4.3.3.57. Allan: We need more time on this. 4.3.3.58. Straw poll tabled. 4.3.3.59. Line 171. Deferred. Should be taken care of in recirc ballot.

4.4. Closing

4.4.1. Recess 4.4.1.1. Dorothy: We are out of time. 4.4.1.2. Recess at 1530.

5. Thursday Morning Session, May 17, 2007

5.2. Opening

5.2.1. Call to Order 5.2.1.1. Dorothy Stanley (DorothyS): I call the meeting to order. 5.2.1.2. Meeting convened at 1031 hours. 5.2.1.3. This afternoon we shall change from the listed room to Saint Maurice.

5.3. Process

5.3.1. Presentation of Objectives Document 05/0827r12 5.3.1.1. Dorothy: Let’s revisit the objectives in document 05/0827r12, and look at the items color coded therein. Look at the actions where there has been no progress. Is there an objection to deleting 1400 Access Control

Mechanisms? One individual indicated interest previously. No interest in this meeting. 5.3.1.2. JoeKwak: I think we should not delete anything, rather just keep it inactive and leave it for a historical record. 5.3.1.3. AllanT: Perhaps we could move it to a different section of the document. 5.3.1.4. Dorothy: We’ll do that. How about 1410 Management Message Timeliness. Moved to inactive. 5.3.1.5. 1500 Client Management Protocol. No change. 5.3.1.6. 1900 Regulatory Requirements. No change. 5.3.1.7. 2000 Dynamic Channel Selection. No change. 5.3.1.8. 2010 Power Save. No change: three active presentations. 5.3.1.9. 2020 AP Firmware Update. Move to inactive. 5.3.1.10. 2030 AP Load Balancing. No change. 5.3.1.11. 2040 Deferred Management. Stays active. 5.3.1.12. 2041 Spectrum Etiquette: Active, no change. 5.3.1.13. 2050 Access Point Coordination. Any objection to moving to inactive? Yes, Alex Ashley (active presentation). 5.3.1.14. 2060 Virtual Access Point. No change. 5.3.1.15. 2070 Diagnostics and Troubleshooting. No change 5.3.1.16. 2071 Contention. No change. 5.3.1.17. 2080 Advanced Antennas. Move to inactive. 5.3.1.18. 2090 Location. No change. 5.3.1.19. 2100 Adaptive Rate control, 5.3.1.20. Allan: Rate advertisement and selection as part of FBMS. 5.3.1.21. PeterE: There were many options on rates for UC/MC/BC. 5.3.1.22. Sudheer: There was addition of MC frames with different rates. 5.3.1.23. Decision is no change. 5.3.1.24. 2110 Frequent Handover Avoidance 5.3.1.25. Interest in 2110. Move to inactive? Yes. 5.3.1.26. 2110 Frequent Handover Avoidance. Inactive. 5.3.1.27. 2120 Multicast Enhancements. No change. 5.3.1.28. Dorothy: The document will be updated and posted showing these changes.

5.4. Process

5.4.1. Presentation of Document 07/467r1 5.4.1.1. JoeKwak (Interdigital) presented document 07/467r1 on Interference Measurements. There is a need to measure RFI, but although not currently a capability of 802.11, it could be added. The presentation has been given previously, and enhancements have been added. Interference defined as not thermal, not intended signal, rather everything else. The presentation outlines methods by which interference may be inferred from available measurements (e.g., RSNI, ANPI), maintained performance statistics (e.g., error count, CCA), and their derivatives. A list of simple measurands is provided. Using these measurands in triggered mode, APs can provide otherwise unavailable, but nevertheless valuable information. The presentation observes that 802.11k will allow the enabling measurements, but not the continuous sampling required to accommodate the interference determination.

5.4.1.2. BrianHart (Cisco): Seems useful, but not sure how effective it can be to use the error count (FER) due to complications of feedback control systems such as rate adaptation. 5.4.1.3. JoeK: Already trouble with things like Bluetooth. In a perfect world FER not very useful, but in a real interference environment in unlicensed operation, this is valuable. 5.4.1.4. FloydBackes (Autocell): Surprised we don’t already have this in the spec. The request element should consider adding a identifier specifying the number of samples. 5.4.1.5. JoeK: This was a trouble with “k”. Measurement is a secondary function, so difficult to know what happened or what didn’t. Now I prefer the “best effort” measurement approach. 5.4.1.6. Jason(Broadcom): What happens when RSNI gets close to thermal noise. How do we avoid mistaking the thermal noise from real interference. 5.4.1.7. JoeK: We are looking at abrupt changes due to traffic going on in the system, rather than constant information. 5.4.1.8. Jason: How could this work with a wide range of interference levels and types. Could simulations be produced? 5.4.1.9. JoeK: The behaviors could be explored via simulations, however these would have to be rough indications of value only. It is possible that the measurements could be bounded with thresholds for acceptable accuracy in the result. Not our goal to specify all of the characteristics of the measurement capability. 5.4.1.10. BrianHart: The simulation provides an existence proof. As an example, FER could produce undependable results. You should be able to use “k” measurements to get the data. 5.4.1.11. JoeK: The real key is that “k” based measurements may not be able to provide the continuous sampling. There are varied opinions here. 5.4.1.12. Brian: The simulation provides a 1st order proof that this will work in the real world. 5.4.1.13. SudheerMatta: If you have triggered measurements, you may fail because the trigger will come after the interference has passed. Are you trying to introduce triggered measurements for new parameters. 5.4.1.14. JoeKwak: I am advocating reads on counters that already exist for FER. 5.4.1.15. Sudheer: Everyone uses counters to get FER, but all proprietary. We shouldn’t standardize it. 5.4.1.16. JoeK: We should standardize it. Similar problem with non-standardized RSSI. 5.4.1.17. Allan: Practicality of this is in question. The triggered measurement would occur when the threshold is met. The STA is going to transmit when it has high interference. 5.4.1.18. JoeK: The threshold setting would be a tool that could be adjusted to give the desired result. 5.4.1.19. Allan: Too high, unusable. Too low, many frames flooding network. 5.4.1.20. JoeK: Same as multicast diagnostics. 5.4.1.21. Allan: Suggest simulations. 5.4.1.22. Straw poll 5.4.1.23. Do you support use of this simplified Triggered Interference Request Report? 5.4.1.24. Yes 10, No 7, Abstain 9.

5.4.2. Presentation of Document 07/468r1 5.4.2.1. JoeKwak (Interdigital) presented document 07/468r1 on Preferred Channel. Scanning. Scanning for service is a big part of battery drain in real clients. Originally this was presented as a distributed solution, which was then rewritten for AP control. There was concern regarding regulatory considerations. Dialog with individuals familiar with regulation were doubtful of its ability to function with current device designs that practice DFS, but felt there were no real regulatory problems. This presentation provides a further simplified procedure with normative text to implement the function. The power saving results from reducing the number of channels a client must scan to find service. A facility providing service determines an active channel and sends periodic information identifying the channel. A client scanning that channel and finding no radar activity need not scan any other channels in the regulatory class. For each regulatory class, one channel is chosen. That channel is rotated. The preferred channel is sent often enough that it will be easily found. The technique is claimed to have a large benefit in standby time. APs can designate proxy STAs to take on notification duty. The transmission of the Net Advice Frame by STAs provides information in lieu of an active BSS. Normative text in document 07/0118r4 was also reviewed. Complexity is claimed low for all but the DFS case, but still limited, but with potential for saving 75-80% of battery power that would otherwise be used scanning. 5.4.2.2. Sudheer: The utility of the Net Advice frame. 5.4.2.3. Joe: Tells where service is available. 5.4.2.4. Sudheer: No SSID advertised. So how does it work? 5.4.2.5. JoeK: When it finds a BSS it decodes the SSID when it moves to the active channel. The information is just a pointer, not all the BSS information. 5.4.2.6. Sudheer: The DFS radar detection process could inhibit transmissions for a period of time, but that doesn’t seem included in the text. 5.4.2.7. JoeK: If DFS is detected there is a slightly more complicated process, which is believed acceptable under regulatory constraints. 5.4.2.8. QiWang: All STAs go to the same channel? What if other BSSs exist? 5.4.2.9. JoeK: The requirement is satisfied if only one is present. The first one sets the network advice frame. Anyone else will see no further advertisement is required. 5.4.2.10. Qi: If you have two overlapping BSS, is the Net Advice the same for both? 5.4.2.11. JoeK: Yes. 5.4.2.12. Qi: This would seem to produce more contention, as STAs will seek one preferentially over the other. 5.4.2.13. JoeK: Net advice is only on an unused channel. One you are operating, you have nothing to do with the preferred channel. 5.4.2.14. Mandy (Infineon): Preferred channel is selected so sometimes there will be a normal distribution for Net Advice frames. 5.4.2.15. JoeKwak: I believe you may have a fundamental misunderstanding. Net Advice is not transmitted to an AP. It’s more like ambient information. 5.4.2.16. Mandy: Like a broadcast message? 5.4.2.17. Joe: Yes. 5.4.2.18. AndrewMyles: (Non-DFS case) No BSSs are operating. You set up an AP. You select a preferred channel to operate. The AP has one of its stations to send net advice on another channel. A random new station comes along and sees net advice, but chooses not to jump to it. Instead it looks around. 5.4.2.19. JoeKwak: Net advice is only provided by one BSS. That is sufficient. If there are two overlapping BSSs, then another AP could advertise.

5.4.2.20. AndrewMyles: But in the general case, it’s an advantage for both of them to advertise. But all if all APs wanted to provide the info, they’d have to have both monitoring and operating radios. 5.4.2.21. JoeKwak: That’s the difficult thing. Most APs don’t have this yet. Right now limited to APs that could do it. Who has responsibility to do DFS detection? Everyone. 5.4.2.22. AndrewMyles: But every AP would have to have two radios. 5.4.2.23. JoeK: No, only the one wishing to advertise. 5.4.2.24. Brian Hart: Everyone has described the selection of the channel as random. It does not appear to be random. 5.4.2.25. JoeK: We went over this at the last meeting. 5.4.2.26. BrianHart: The STA going to the preferred channel will get recruited to give net advice. 5.4.2.27. JoeK: We’ve covered this in the past. The AP would usually perform the function. If an STA is chosen, the choice is not discriminating (e.g. could choose STA low on power). We may want to consider other factors in the choice. 5.4.2.28. EmilyQi: Interesting problem, but can be resolved by 802.21 neighbor report. 5.4.2.29. JoeK: The intelligent long-term solution, yes. But for now, this would fill the gap. Ubiquitous Wi-Fi coverage also would displace this. 5.4.2.30. Move to include normative text from 11-07-0118-04-000v-normative-text- preferred-channel.doc into TGv draft D0.12 5.4.2.31. Moved: Joe Kwak 5.4.2.32. Seconded: Bob Miller 5.4.2.33. For 5, Against 10, Abstain 6. The motion fails. 5.4.2.34. JoeKwak: I shall work with those who have regulatory concerns and will bring this back next time.

5.4.3. Evaluation of Letter Ballot Readiness 5.4.3.1. Dorothy: We show in our schedule going out for letter ballot at this meeting. I’d like to have some discussion regarding whether we should go to letter ballot now or wait until May. 5.4.3.2. Allan: If the majority thinks July, we should make sure that we have a focus for the meeting toward that goal. I would suggest not rehearing presentations that have been given before. 5.4.3.3. Brian: I think new things need a hearing. 5.4.3.4. BobMiller: Since the beginning of TGv we have had a process for moving toward completion which as taken into account the items the group feels are important and then addressing them. I believe that system has been working, as we have moved progressively closer to satisfying the loose objectives we set. We did that by allowing new presentations and building consensus through initial and subsequent improved presentations. I strongly recommend we do not foreclose new or in-process contributions just to speed the process. 5.4.3.5. Peter: I agree. Regulatory issues in process need a venue for working. This is the only group that can take them forward. 5.4.3.6. Dorothy: We need a balance between speed and focus to optimize our planning process. 5.4.3.7. JoeKwak: There is a lot of new material in the draft. Priorities are always difficult to set. We have to realize that all of the work is not done. Peter mentioned regulatory. Jari presented other considerations. Getting done is not a priority that should displace everything else.

5.4.3.8. Allan: Not stating shutting out new stuff, but some repeat presentations have not had growing consensus.

5.5. Closing

5.5.1. Recess 5.5.1.1. Dorothy: We are out of time. We are recessed. 5.5.1.2. Recess at 1230 hours.

6. Thursday Afternoon Session, May 17, 2007

6.2. Opening

6.2.1. Call to Order 6.2.1.1. Dorothy Stanley (DorothyS): I call the meeting to order. 6.2.1.2. Meeting called to order at 1330.

6.3. Process

6.3.1. Discussion on When to Letter Ballot 6.3.1.1. We want to discuss comment resolutions, when we will elect to go to letter ballot, and planning for the July meeting. The decision to go to letter ballot does not mean that nothing more will be added to the draft, but rather to offer a larger audience for the work. 6.3.1.2. Floyd: While there are still objectives that have not been met, but which have gotten support in straw polls, I am reluctant to go to letter ballot. I favor waiting for the July meeting. 6.3.1.3. RogerDurand (RIM): Is it even possible that we could go to letter ballot this meeting? 6.3.1.4. Dorothy: To go to letter ballot we would have to pass a couple of motions. These would deal with empowerment of the editor to create a new draft, and request to go to a letter ballot. 6.3.1.5. Dorothy: Let’s have a straw poll… 6.3.1.6. TGV should go to first letter ballot 6.3.1.7. (a) At this May meeting (current schedule) 6.3.1.8. (b) At the July meeting 6.3.1.9. (a) 4 (b) 10 6.3.1.10. Dorothy: We shall try for July. We have a schedule that currently shows us completing not until 2H09. That really pushes the limits on what the process can tolerate. I will probably forecast a completion of January. The current draft is 171 pages. We need to deliver this standard to the industry.

6.3.2. July Meeting Planning 6.3.2.1. Dorothy: We have a number of known July presentations, and I’d like to hear if there are any more: 6.3.2.2. [adds to list] 6.3.2.3. [Secretarial Note: This listing not exhaustive] 6.3.2.4. Topic - Lei Du 6.3.2.5. Tentative – Leader-Based Multi-cast Yongho Seok

6.3.2.6. Sleep Mode with AP Filtering – Matt Smith 6.3.2.7. Multi-Level Power Control – Floyd Backes 6.3.2.8. TIM Broadcast – Menzo Wentink 6.3.2.9. Joe Kwak – Preferred Channel – 20 6.3.2.10. Joe Kwak – Interference Diagnostics – 20 6.3.2.11. Alex Ashley – AP Collaboration 6.3.2.12. Dorothy: Any objection to scheduling teleconferences June 14th and Jun 28th at 1700 Eastern, 1 hour. Yes. 6.3.2.13. Roger Durand: Suggest 1000 Eastern to accommodate Asian members. 6.3.2.14. Agreed to by group. 6.3.2.15. Dorothy: Are there any other meeting issues. No. Very well, let’s turn to completing the comment resolution business.

6.3.3. Comment Resolutions 6.3.3.1. Dorothy: We have a number of motions in queue. Shall we work on these? The first is CID #233. 6.3.3.2. Emily: Shows document 07/0795r0. This comment deals with incorrect table information for table 26, section 7.3.2. 6.3.3.3. Move to incorporate normative text from 11-07-0795-00-000v-comment- resolution-cid233 into TGv draft D0.12, to resolve CID #233. 6.3.3.4. Mover: Emily Qi 6.3.3.5. Seconder: Floyd Backes 6.3.3.6. Dorothy: May we approve unanimously? Yes. 6.3.3.7. Result: Unanimous consent. 6.3.3.8. Emily: The next one is shown. This allows bundled resolutions, excluding CID #164 and #196 in document 07/0802r0. 6.3.3.9. Move to adopt comment resolutions from 11-07-802-00-000v-tgv-d0-10- validation-review-comments-ecsa and include text changes in TGv draft D0.12 except for CID #164 and #196 6.3.3.10. Mover: Emily Qi 6.3.3.11. Seconder: Peter Ecclesine 6.3.3.12. Result: Unanimous consent. 6.3.3.13. Dorothy: Now we should address CID #35 from yesterday. 6.3.3.14. To address CID #(35) asking to minimize the number of IEs, we should 6.3.3.15. – a) move elements included only in action frames into the action frame definition, and combine elements as the commenter suggested 6.3.3.16. – b) create a new wireless network management information element, with subtypes for all added information elements 6.3.3.17. – c) defer for now, and resolve if needed in LB 6.3.3.18. JoeKwak: a) and b) are not orthogonal. We could do both. We should do a), b), or a) & b). 6.3.3.19. Dorothy: How about multiple voting? 6.3.3.20. JoeK: OK 6.3.3.21. Adrian: We have used 70 of 200 entries in the ANA database 6.3.3.22. David Hunter: There were lots of legacy IEs before “v” came along. It would seem making a list for v would produce two lists. 6.3.3.23. a) 9, b) 8, c) 6 6.3.3.24. Dorothy: Let’s tee up for later discussion, perhaps fix before letter ballot. Let’s resume examination of the “General” comment category. 6.3.3.25. Emily: Resumes General comment category discussion from yesterday. Submission page 25 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

6.3.3.26. in document 07/0735. . [Secretarial Note: The following represents highlights of the discourse, and is not exhaustive. Consult the document for the comment numbers, comments, dispositions and recommended resolutions.] 6.3.3.27. Line 171. Counter. 6.3.3.28. Line 174. Deferred. Related to 171, also 203 6.3.3.29. Line 204. 206 Defer. Perhaps left to LB 6.3.3.30. Line 208-209. Counter. 6.3.3.31. Line 210-213. Vendor Specific Items. Accepted. 6.3.3.32. Line 221. Already implemented 6.3.3.33. Line 222. Counter. 6.3.3.34. Line 224-226. Counter. Editorial comments. 6.3.3.35. Line 248. Deferred. 6.3.3.36. Line 281. Accepted. 6.3.3.37. Dorothy: Question on first one. Line 154. We should not need a motion for an introduction? 6.3.3.38. PeterEcclesine: Everything in front of the table of contents will be filled in by staff. 6.3.3.39. JoeKwak: The front end is for our own benefit. It may not end up in the final document. We tried in “k”, and eventually moved it to section 5, which is a sort of application tutorial. 6.3.3.40. Dorothy: Do we need an introduction, though? That’s what the commenter asked. Bill Marshall? 6.3.3.41. BillMarshall: This will be folded into the base standard, but until then it will be published separately. During that time, it could be useful for potential implementers and ballot voters to better-understand the amendment and the problem it is trying to solve. 6.3.3.42. Dorothy: Is there any objection to having introductory text? 6.3.3.43. Peter: I will be real hard to write. 6.3.3.44. Dorothy:Take a look at 715r1. 6.3.3.45. Move to adopt the comment resolutions in 11-07-0735-01-000v-comment- resolutions-tgv-d0-10-validation-review-comments-general except for CID #2, #35, #143, 144,145,146, 233 and deferred comments, and incorporate the indicated text changes into the TGv draft. 6.3.3.46. Moved: Emily Qi 6.3.3.47. Seconded: Allan Thomson 6.3.3.48. For 8, Against 0, Abstain 12. The motion passes. 6.3.3.49. JariJokela: We could look at resolutions in documents 07/0709 on interference. . [Secretarial Note: The following represents highlights of the discourse, and is not exhaustive. Consult the document for the comment numbers, comments, dispositions and recommended resolutions.] 6.3.3.50. Line 250 Deferred 6.3.3.51. Line 251 Declined – See recommended change 6.3.3.52. Line 252 Accepted – See text change 6.3.3.53. Line 253 Counter – See replaced text. 6.3.3.54. Line 254 Accepted – Correct text. 6.3.3.55. Move to accept the comment resolutions in 11-07-0708-00-000v-tgv-draft-0- 10-interference-resolutions except for CID #237 and incorporate the indicated text changes into the TGv Draft 0.12 6.3.3.56. Moved: Jari Jokela 6.3.3.57. Seconded: Allan Thomson 6.3.3.58. Result: Unanimous consent Submission page 26 R. R. Miller, AT&T May 2007 doc.: IEEE 802.11-07/0684r1

6.3.3.59. Dorothy presented multicast diagnostics and virtual AP comment resolutions in document 07/0753r0, beginning with diagnostics. . [Secretarial Note: The following represents highlights of the discourse, and is not exhaustive. Consult the document for the comment numbers, comments, dispositions and recommended resolutions.] 6.3.3.60. Line 7. Declined. We are not sure how to distinguish this case. 6.3.3.61. Line 8. Declined. Both are supported 6.3.3.62. Line 9. Counter. (Accept with slightly different wording) 6.3.3.63. The Virtual AP resolutions were reviewed next… 6.3.3.64. Line 2. Reject. Misunderstood by commenter 6.3.3.65. Line 3. Accept. 6.3.3.66. Line 4. Accept. Indicated as field always present. 6.3.3.67. Line 5. Counter. Delete table and add text to list IEs that are always present. All others not mentioned are optional. Will minimize need to have another table that will have to be sync’d. 6.3.3.68. MooRyong: Asks for clarification on persistence of some text in resolution. [clarified, text found to be present]. 6.3.3.69. Move to adopt the comment resolutions in 11-07-0753-00-000v-d0-10- validation-review-comments-multicast-diagnostics-and-virtual-ap and incorporate the indicated text changes into TGv Draft 0.12. 6.3.3.70. Mover: Allan Thomson 6.3.3.71. Seconder: Matt Fischer 6.3.3.72. Result: Unanimous consent 6.3.3.73. Allan Thomson reviewed comments in document 07/0716r0 on presence. [none of these had suggested solutions, so Allan fabricated text] 6.3.3.74. Line 193 6.3.3.75. Line 194 6.3.3.76. Line 195. 6.3.3.77. Line 196.Reject – Unclear as to reference (Marshall looking at text) 6.3.3.78. BillMarshall: In the IE, the timing measurement sub-element is inappropriately described. The specified range could be covered with fewer octets. Suggest just specifying the value in ms, usecs, etc. Depending on the precision required, one could better use floating point representation. 6.3.3.79. Dorothy: I recall some sensitivity on resolution at the time this was put into the text. 6.3.3.80. [Marshall, Thomson, Stanley and group decide to reject comment] 6.3.3.81. Line 197. Accept. See changes. 6.3.3.82. Line 246. Accept. Change text. 6.3.3.83. Line 258. Accept/Counter. Change text 6.3.3.84. Dorothy: I suggest we pull that one out, by virtue of discussion w/Adrian who intends to write comment in letter ballot on this. 6.3.3.85. Line 261. On Antenna ID. Correct and reference to TGk 6.3.3.86. Line 272. Accepted. Change text. 6.3.3.87. Line 278. Reject. See resolution regarding disposition of request/response w.r.t. XML for CIVIC or GEO. 6.3.3.88. Move to adopt the comment resolutions in 11-07-0716-00-000v-tgv-draft-0- 10-presence and incorporate the indicated text changes into TGv Draft 0.12 6.3.3.89. Mover: Allan Thomson 6.3.3.90. Seconder: Emily Qi 6.3.3.91. Result: Unanimous consent.

6.3.3.92. [Secretarial Note: The CID disputed by Adrian was stricken from the motion at Allan’s request. 6.3.3.93. MooRyongJeong (DoCoMo) presented comments on traffic generation in document 07/779r0. 6.3.3.94. Both comments can be resolved with the same resolution. 6.3.3.95. Line 271. Counter – See changed text 6.3.3.96. Line 274. See comment 271 6.3.3.97. Move to accept the comment resolutions in 11-07-0729-00-000v-tgv-draft- traffic-generation and incorporate the indicated text changes into the TGv Draft 0.12. 6.3.3.98. Mover: Emily Qi 6.3.3.99. Seconder: Alex Ashley 6.3.3.100. Result: Unanimous consent. 6.3.3.101. Dorothy: I think we have gone through all of the presentations. In “General” there was a comment about an introduction. We will incorporate an introduction. 6.3.3.102. Move to incorporate normative text from 11-07-0715-01-000v-inttroduction- text into TGv draft 0.12 Introduction clause, to resolve CID #2 6.3.3.103. For 9, Against 0, Abstain 14. The motion passes. 6.3.3.104. Emily Qi presented resolutions from document 07/0750r1 on measurements. [Secretarial Note: The following represents highlights of the discourse, and is not exhaustive. Consult the document for the comment numbers, comments, dispositions and recommended resolutions.] 6.3.3.105. Line 262. Deferred Normative text submission. 6.3.3.106. Line 263. Related to 262. 6.3.3.107. Line 264. Deferred. 6.3.3.108. Line 265. Deferred. Normative text needed. 6.3.3.109. Line 266. Deferred. 6.3.3.110. Line 267. Rejected. Different groups have different identifiers. 6.3.3.111. Allan: More reasonable to accept it. Take a look at the long table. Would need normative text. 6.3.3.112. Line 268. Deferred. 6.3.3.113. Emily: There will be no motion on these. 6.3.3.114. Allan: Majority of resolutions will follow TGk? Right? 6.3.3.115. Emily: Yes. 6.3.3.116. Dorothy: We have about 20 comments left.

6.3.4. Editor Empowerment to Create New Draft 6.3.4.1. Move to instruct the editor to create draft 0.13 incorporating changes to the TGv draft D 0.12 approved at the May 2007 meeting. 6.3.4.2. Moved: Allan Thomson 6.3.4.3. Seconded: Floyd Backes 6.3.4.4. Result: Approved unanimously 6.3.4.5. Dorothy: Is there any other business? No.

6.4. Closing

6.4.1. Adjourn 6.4.1.1. Is there a motion to adjourn? Yes.

6.4.1.2. Any objection to adjourn? None. 6.4.1.3. TGv is adjourned. 6.4.1.4. Adjourn at 1510.

Submission page 29 R. R. Miller, AT&T