Doc.: IEEE 802.11-08/1353r0
IEEE P802.11
Wireless LANs
|November 2008 Meeting Notes |
|Date: 2008-11-19 |
|Author(s): |
|Name |Affiliation |Address |Phone |email |
|David Goodall |G2 Microsystems |24 Campbell St |612 9213 2529 |david.goodall@g2microsys|
| | |Haymarket NSW 2000 Australia | | |
|Dorothy Stanley |Aruba Networks |1322 Crossman Ave |+1 630-363-1390 |dstanley@arubanetworks.c|
| | |Sunnyvale, CA 94089 | |om |
Monday November 10, 2008 PM2 Session – 16:00 – 18:00
1. Chair (CH: Dorothy Stanley, Aruba Networks) called the meeting to order at 16:00, welcomed participants and reminded participants to record their attendance.
1. CH:Reviewed the patent policy slides
2. CH: Asked for essential patents/patent holders, per patent slide instructions. None brought forward.
3. Agenda is in 08-1200-00, on the server
4. CH:Reviewed the status of the group
5. CH, membersAdjustements to the agenda, per member requests for times for their presentations. Updates will be posted as 08-1200-01
2. CH: Is there any objection to adopting the Agenda shown? No objection, adopted by unanimous consent (Motion 1)
3. Presentation by Joe Kwak (JK,Interdigital) 08-1262-01
1. JK: Only difference between this document and the -00 is the typo identified on the conference call. Reviewed motivation for this presentation. Use of UTC is trivial if have one reference point is provided, incorporates the commenter’s suggestion. Added UTC to Event Request. IF AP doesn’t have the value, indicates this. STA can use UTC if it has the info, which was not provided in the request.
2. CH: Thank you. Are there questions for Joe?
3. Qi Wang (QW, Broadcom) – What happens if the AP does not have the value, why is even a short field provided?
4. JK – Needed for parsing the field values.
5. David Hunter (DH, Panasonic) – Is this an ESS wide value – similar to mobility domain, is this UTC domain?
6. JK – Logs are not cancelled upon a transition to a BSS in the same ESS.
7. DE Engwer (DE, Nortel Networks) – Table V6. There are many uses of the term “UTC time”, but no definition. Have the acronym defined in clause 4. ISO documents exist for definitions.
8. JK – There are many standards documents that define UTC formats, none meet our needs. Term has a general English meaning.
9. CH: No more questions seen. Suggest hearing next presentation on same topic, then discuss way forward.
4. Presentation by Allan Thomson (AT, Cisco Systems) 08-1309-00
1. AT - General approach for distributing UTC time, enables use of the time by other & future applications. Add to Beacon, Probe Response frames, sent out every 1024ms, at least. Can be used to adjust for clock drift
2. CH: Thank you. Are there questions for Allan?
3. DH – Can the field be included in every Beacon frame?
4. AT – Yes, not prohibited, but concerned with beacon bloat, don’t require the field in every Beacon.
5. JK – real question is if .11 should expamd to include UTC for all applications. Only application found to date is for event reporting (in many years). If there is no general use, then include only in event. If there is a general use, then ok.
6. Peter Ecclesine (PE, Cisco Systems) – What happens is synchronization with the TSF is not maintained. Second qualifier – control and status – need to indicate both.
7. Graham Smith (GS, DSP Group) – Need to see use cases. Do we need 1ms in real-world time, or do we need day of the week time. Do we need 2 times?
8. AT – Not replacing the TSF, rather in addition to it. The TGv event reporting feature.
9. JK - No claim of synchronization, just a reference point.
5. Straw poll 1 –
1. UTC Time availability should be General/Local/Abstain.
2. Result: General – 5, Local – 6, Abstain – 12
6. Presentation by Jing Zhu (JZ, Intel Corporation) 08-1010-03
1. JZ- reviews the document, and the 3 alternate wordings proposed.
2. Jon Rosdahl (JR, CSR) – Support this idea, select one of the wordings, polish language going forward.
3. PE –Language in option 2 is not as direct as that in option 1.
4. QW – Appraciate Jing’s efforts to work on this. Still not convinced that the bit is useful. Need to hear how the bit will be used. When ACK is used, no difference between the receive and transmit interference. Corner cases are identified that clain to use this. However, look at the corner cases, MC/BC – no need for AP to know that transmitter is inhibited, unless all stations would have the same exact inhibition. Delayed ACK, Regular Block ACK are still sent, or are sent at a pre-defined delay time. How can the AP schedule to use this. Doubt that it can ever work. For collocated interference, scheduled access in .11 is not practical. RX/TX provides an even higher layer of granularity. Adding the bits creates a false expectation on the part of the user.
5. JR – Believe the capability is beneficial, implementation specific application. Identify the type of interference, focus on the definition, rather than implementation.
6. JK – This isn’t a big deal, proliferation of wireless devices means that collocated interference exists.
7. Roger Durand (RD, RIM) – All interference is receive interference.What is new here is tx vs rx. When you’re communicating, may not get an ACK back.
8. QW – The standard can always be updated later. Discuss potential use cases, can update when useful, otherwise setting a flase expectation on what is supported.
9. PE– A device that can’t transmit or is not receiving is not compliant with the standard.
10. GS – Can see how this is useful, for example when a DECT device is collocated. But can’t communicate what is needed with only one bit.
11. JR – Meets applications today and planning of transmissions is happening today.
12. QW Please bring an example.
13. AT – Have seen no info on how this works.
7. Straw Poll 2– Prefer the option 1, option 2, option 3, None, Abstain text in 1010-03
1. Option 1 – 3, Option 2 – 0, Option 3 – 0, None – 1, Abstain – 18
8. Straw Poll 3 – The approach in 1010 should be added to the TGv draft
1. Yes -10, No – 6, Abstain – 6
9. CH: Reviewed the agenda, plan for the upcoming evening session.
10. Recess at 18:00
Monday November 10, 2008 Evening Session, 19:30-21:30
11. Chair called the meeting to order at 19:40, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
12. Presentation by Ganesh Venkatesan( GV, Intel Corporation) 802.11-08/0891-r1 Timing Measurement
1. GV – Goes through presentation. Slide 14 needs correction +- 20 nanoseconds at start of diagram
2. Kapil Sood (KS, Intel Corportation) – question clarifying retransmissions. Protocol requires ACKs to complete.
3. Jim Petronovich, (JP, Visat): requesting a submission explaining how the timing tolerance can be met.
4. QW – similar concern on accuracy assumptions with respect to manufacturing variations etc.
5. Neil Warren, (NW, Apple) – tolerance should be attainable.
6. JP - concerns about multipath variation
7. Kevin Stantan, (KSt, Intel Corporation) – addresses concerns on multipath
8. JP - would still like a submission
9. GV - refers Jim to existing submission 1229-R1
10. KS – joint 802.11AA/802.1 meeting Thursday 8-10 top down presentation on this topic
11. QW - asks for information to be sent to 11v reflector, Ganesh to do this.
12. GS – slide 6 why use the ACK for the timing measurement?
13. GV– gives quickest feedback
13. 20.20 Presentation by Qi Wang< Broadcom Corporation, 802.11-08/1327-r1 resolutions to LB133 CID 1239, 1257
1. QW - reviews the current document
2. EQ – question on 11.2.1.13 dot11WirelessManagementImplemented – what happens if false
3. GV – commented on an umbrella statement for the negative case
4. AT – okay with text
5. EQ – thinks first sentence not required
6. Bill Marshall (BM, AT&T) - thinks first sentence not required, keep mandatory statements but not optional ones.
7. Matthew Fisher (MF, Broadcom) - No normative word in sentence
8. MH – TIM broadcast is optional and a sta that implements TIM broadcast shall set the MIB attribute to true.
9. John Fuller (JF, self-affiliated) - TIM broadcast is optional and a sta that implements TIM broadcast shall set the MIB attribute to true and must have implemented dot11WirelessManagement
10. MF – Second sentence does not follow IEEE style guide.
11. MH – problem with ‘supports’
12. MH – recommends TIM broadcast STA, proxy ARP STA etc to get around problem
13. BM – problem with ‘sets’, similar to ‘supports’. Recommends a station that implements TIM broadcast has the MIB variable set to TRUE, and this MIB variable should be read-only.
14. Chair- Suggest WNM STA == a STA for which dot11WirelessManagementImplemented is true. The implementation of TIM Broadcast is optional for a WNM STA, and is disallowed for a non-WNM STA. A STA that implements TIM Broadcast has the MIB attribute dot11MgmtOptionTIMBroadcastImplemented set to true.
15. AT – STA must implement mandatory features in order to implement optional features or the entire specification must be revised.
16. Jouni Malinen (JM, Atheros) – leave the PICs to define optional and mandatory features.
17. QW – 11v has two MIB variables
18. Brian Hart, (BH, Cisco) – in favour of ‘disallows’
19. Joshua Zhou (JZ, Atheros) – why are we disallowing features?
20. EQ– then make all features optional
21. BM – not in favour of disallowing in case it causes problems in other areas of the spec
22. AT – 11.20.1 text: When dot11MgmtOptionTIMBroadcastImplemented is true, dot11WirelessManagementImplemented shall be true.
23. Final Rewrite?
1. The implementation of TIM Broadcast is optional for a WNM STA
2. A STA that implements TIM Broadcast has the MIB attribute dot11MgmtOptionTIMBroadcastImplemented set to true.
3. When dot11MgmtOptionTIMBroadcastImplemented is true, dot11WirelessManagementImplemented shall be true.
24. AT – suggests similar treatment for Event request and event report as for TIM broadcast
25. Daniel Borges (DB, Apple) – how does this reflect the PICs?
26. CH – it is the same as the PICS
27. AT – comment on PICS - WNM 2 has lost consistency
28. QW – will check
29. Discussion on various aspects of the PICs.
14. Motion :
1. Motion to approve minutes from September and teleconference meetings to November.
2. Mover: Ganesh Venkatesan
3. Seconder: Emily Qi
4. Result: Unanimous
15. Motion
1. Motion to adopt TGv draft 3.02 as current TGv draft.
2. Mover: Allan Thomson
3. Seconder: Ganesh Venkatesan
4. Result: Unanimous
16. Motion :
1. Motion to adopt changes in 1197-04 into TGv d3.02.
2. Moved: Allan Thomson
3. Seconded: Emily Qi
4. Result- 8-0-3 Passes
17. Recess until 10:30 Tuesday
Tuesday November 11, 2008 Morning AM2 Session, 10:30-12:30
18. Chair called the meeting to order at 10:30, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
2. Chair reviewed the agenda, see 08/1200r1
3. Management frame priority moved to Wed PM1
1. AT: Objection to move to Wed PM1 based on experts being available for this time slot.
2. CH:: The presenter wants to move to Wed PM1
3. Mike Montemurro (MM, RIM): confirmed, request move to Wed PM1
4. AT - ok
5. CH: 08-1321 and 08-1322 also moved to Wed PM1
6. BM: 08-0419-R3, 1059-R1 ready for discussion Tue PM2, documents are on the server
7. CH: called attention to update of timing sync normative text 08/1229-01
19. Presentation by Allan Thomson, Cisco - 08-1284 Additional TIM CIDs
1. MH: Why is normative text in clause 7?
2. AT: This is also captured in clause 11
3. Discussion on changes in clause 11.
20. Presentation by Allan Thomson, Cisco - 1013-r6 Additional Diagnostics Edits
1. EQ - Question on page 18, 11.20.4.3, about sentence “When more than one Antenna type supported etc”. Referred to 7.3.2.65.2 where information appears to be duplicated in Table v16.
2. AT Table v16 does not cater for multiple antenna types.
3. EQ: Prefer to change 11.20.4.3 to say “When more than one Antenna Type is supported, multiple Antenna Type sub-elements shall be included in the Manufacturer etc
4. CH: queried if normative references still required.
5. AT - Confirmed normative references no longer required.
6. Peter Ecclesine (PE, Cisco Systems): confirmed normative refs are in 802.11u.
21. Presentation by Allan Thomson, Cisco - 08/1282-r0 Collocated Device Diagnostic
1. AT: New collocated device types and table device added.
2. AT - Changes to 11.20.3.3 Manufacturer Information STA Report similar to changes in 1013-r6.
3. QW: Last sentence of 11.20.3.3 If no collocated device supported, what does that mean? Suggested change “If the existence or the type of the collocated device is unknown no Collocated Device Type sub-elements shall be included.
4. EQ: Question on use of term “device type” which can be an interfering type of device or a printer or camera. See 3. Definitions.
5. PE: Prefers definition in 3 and change to 11.20.3.3 definition.
6. QW: Querying whether interfering device is on or off. Referred to Definition in 3 where it is defines as either on or off.
7. AT: Responded to definition of “device type” with different options.
8. EQ: Would prefer a definition that distinguishes devices capable of interfering from other devices like printers etc. Will take discussion off-line.
9. PE: referred to 802.21 as origin of definitions.
10. MM: discussion on the table v13a which is to be included in 11v: definitions may need work
11. PE: described background of how 802.21 arrived at the definitions in table v13a.
12. AT: Question to MM: If you have additional concerns/changes please discuss offline.
22. Motion to adopt changes in 11-08-1284-00-000v-additional-TIM-CIDS into TGv draft
1. Moved: Allan Thompson
2. Seconded: Emily Qi
3. See no discussion on motion.
4. Result: Passed 13-0-4 (for-against-abstain).
23. CH: summarized afternoon (PM2) agenda.
1. Attendance log reminder.
24. Recess at 11.15am.
Tuesday November 11, 2008 Afternoon PM2 Session, 16:00-18:00
25. Chair called the meeting to order at 16:00, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
2. Chair reviewed the agenda, see 08/1200r2.
26. Presentation by Bill Marshall, ATT, 08-0419r3 Access Point Collaboration Normative Text
1. BM: 802.11k spectrum management will be in cell phones.
2. Henry Ptasinski (HP, Broadcom): Slide 12 please explain graph of jitter increases with # APs
3. BM: Explanation
4. HP: Querying load on stations as being outside normal operating range.
5. BM: Will need to re-check original results
6. HP: Slide 11 – more APs makes things worse – please clarify the comparison of APs to APs
7. BM: Explanation
8. HP: Not convinced that the comparison is valid if the number of stations is increased, i.e. the test methodology increased the number of APs and stations at the same time.
9. BM: disagrees.
10. HP: Do you have any figures from the same testbed with the AP collaboration mechanism
11. BM: No, the results are simulated.
12. Allan: Slide 14 How many APs are in the simulation?
13. BM: Two APs
14. AT: Alex previously said that AP collaboration worked for two APs but not more. Do you have any results for for APs?
15. BM: In ATT experience the problem can be reduced to a pairwise problem.
16. AT: Slide 13 – In reality sync between Aps is hard to attain.
17. BM: Sync is up to the network manager.
18. AT: Questions whether this can be done.
19. GS: Slide 11 – How does the traffic decrease with the increasing number of APs?
20. BM: Time lost to backoffs causes traffic to decrease.
21. GS: Not convinced.
22. DH: Stations will respect the NAV and go quiet.
23. BM: Main reason is the collision between APs.
24. HP: In terms of results with collaboration enabled do you have any results where a network is not participating, i.e. BSS is not under same control?
25. BM: That case is not included.
26. HP: But that is the common case.
27. Comment - co-author -: The solution and cases are for enterprise deployment.
28. HP: It still appears unrealistic and would like to see more cases.
29. Mark Hamilton (MH, Polycom): Comment on NAVs. All stations will observe NAV. Question: is this uplink or downlink? How did they generate and measure the traffic?
30. BM: Thinks this is downlink TCP/IP traffic but will check.
31. Graham: Slide 14 what is YANs
32. BM: Yet another network simulator.
33. GS: Question on scheduling methodology
34. BM: Equal scheduling on both sides.
35. Peter Ecclesine, (PE,Cisco): Item 4, next to last line on p3. Does not have the required function. The channel change is asynchronous and cannot be scheduled.
36. BM: It’s synchronous in the beacons until it occurs.
37. JK: Slide 11 – presented a conceptual way to understand data on slide 11. Decreasing traffic with additional APs is due to the additional amount of contention.
38. HP: Wrt Peter E’s question on immediate channel change, channel change must be asynchronous right?
39. BM: Yes
40. PE: But the language prohibits this.
41. HP: yes
42. PE: Once the suppression interval starts the AP is stuck there.
43. BM: yes but this is not a problem because it is the same as radar detection case.
44. HP: The AP needs to be able to send traffic if it must during any quiet period.
45. BM: It can do this.
46. PE: That is what is required.
47. BM: Text is in the base.
48. JK: A discourse on contention-based protocols vs time domain, arguing in favour of time domain for coordinating BSSs, in support of the motion.
27. Motion
1. Move to incorporate the changes in document 11-08-0419-03-000v-proposed-resolution-for-cid423-et-al-on-ap-collaboration.doc into the TGv draft, and
1. resolve CID 1274, as “counter”, with a comment resolution of “Incorporate text changes in 08-0419-03” and
2. resolve CIDs 400, 1404, 1411 as “counter”, with a comment resolution of “see CID 1274”
2. Moved: Bill Marshall
3. Seconded: Joe Kwak
4. Result 5-7-8 Motion fails
28. 17.05 Presentation by Allan Thomson, Cisco, 08-1283 r1 Diagnostic Device Type normative text
1. AT: explanation of the changes and the reasons.
2. HP: URL is included to the WFA web site. How does that fit IEEE style guide?
3. PE: Put the URL in a foot note.
4. General agreement on use of foot-note.
5. Emily Qi (EQ, Intel): Why is there inclusion of table v13 if there is an URL to the same information? Question on device type? Question on device types 1-4?
6. AT: Wants to include the WFA device types as is. The table is required because the WFA does not include numerical constants.
7. QW: You need a sentence to say that devices include 802.11. Additional comments on two device types.
8. HP: On Emily’s URL question. The base standard always includes a document rather than a URL therefore the text must include the table.
9. Dave Stephenson: Agrees that table must be included in case the list at WFA changes and again because the WFA list does not include numerical constants.
10. JK: Agrees with including explicit encoding of table. Query on including the term WFA in the text in case of trademark issues. Leave it in the foot note only.
11. EQ: Why mention WFA code category?
12. HP: With respect to URLs 11v need to check use of URLs before incorporating in the base standard.
13. PE: refers to submission 1045 which gives guidelines to editors.
14. AT: wishes to make the motion and incorporate any changes as editorial changes.
29. Motion
1. Move to adopt the comment resolutions for the Diagnostics category comments indicated below, and include the indicated text changes into the TGv draft.
1. CID 163, Counter, “Incorporate the text changes indicated in 08-1283-01”
2. Moved: Allan Thomson
3. Seconded: Brian Hart
4. Result 14-4-3 Motion passes
30. Motion
1. Move to adopt the indicated text changes in 11-08-1013-07-000v-Additional-Diagnostic Edits into the TGv draft.
2. Moved: Allan Thomson
3. Seconded: Emily Qi
4. Result 11-0-7 passes
31. Discussion on 1282r1 Allan Thomson (Cisco Systems)
1. AT reviews text and changes.
2. GS: On Table v13a – is it too late to add DECT?
3. Peter E: for which country?
4. GS: Japan
5. AT: It’s not a closed list and can go in later
6. EQ: Define Zigbee, Bluetooth etc. Can we add Wi-Max
7. PE: Would rather add 802.16 as a catchall and other catchalls.
8. AT: Then we should make the edits now.
9. CH: Is that what you want to do?
10. PE: What does the group want to do?
11. AT: We will modify, repost it and vote tomorrow.
32. Motion
1. Move to adopt the indicated text changes into the TGv draft:
1. In 11.20.3, change from
2. When the IPv4 address being resolved in theARP request packet is used by a non-AP STA currently associated to the BSS, the Proxy ARP service shall respond to the request on behalf of the non-AP STA [RFC 925], unless the packet updates the HardwareAddress to Internet Address mapping. The Proxy ARP service also shall respond to Internet Control Message Protocol version 6 (ICMPv6) Neighbor Discovery packets on behalf of the non-AP STA, to support IPv6 services [RFC 2461], unless the packet updates the Hardware Address to Internet Address mapping.
3. to
4. When the IPv4 address being resolved in theARP request packet is used by a non-AP STA currently associated to the BSS, the Proxy ARP service shall respond to the request on behalf of the non-AP STA [RFC 925]. The Proxy ARP service also shall respond to Internet Control Message Protocol version 6 (ICMPv6) Neighbor Discovery packets on behalf of the non-AP STA, to support IPv6 services [RFC 2461].
2. Moved: Allan Thomson
3. Seconded: Dave Stephenson
4. Result: 7/0/12 (For/Against/Abstain) Motion passes.
33. Motion
1. Move to adopt the comment resolutions for the Traffic Generation category comment indicated below:
2. CID 73 – Declined, “Incorporate the resolution in 11-0801-02, and add “The commenter is invited to submit additional clarifying text”
3. Moved: Fujio Watanabe
4. Seconded: Emily Qi
5. Result Unanimous
34. Presentation by Allan Thomson, Cisco, 08-1262 r1
1. AT presents the redlined changes in the document.
2. JK: Some changes are editorial and are okay. Issue about transmitting UTC and time stamp when they are undefined. They should be optional or send zeroes. Text changes on procedures acceptable.
3. AT: The UTC and time stamp won’t be transmitted unless UTC is available anyway, i.e. the feature is not usable otherwise. The proposal makes the spec simpler.
4. QW: A common time ref across BSS is needed. In our spec on a BSS transition, pending event requests are cancelled. Where does the final report go?
5. JK: Request cancelled means that the report is not sent. Logs are not destroyed on BSS transition but reports are cancelled.
6. QW: Why send a future AP a report with logs that were started by a previous AP.
7. JK: The transition log is important and required.
35. Recess at 16.00.
Tuesday November 11, 2008 Evening Session, 19:30-21:30
36. Chair called the meeting to order at 19:30, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
2. Chair reviewed the agenda, see 08/1200r2
37. 19.35 Presentation by Ganesh Venkatesan, Intel, 08-1229-02 Normative Text for D3.02 Timing Measurement
1. QW: Section 7.4.11.23. Size of timestamp field?
2. Ganesh: The timestamp field is 4 bytes due to size of time of departure timestamp size
3. QW: Why not use TSF plus another 2 bytes for resolution? Other general questions about field sizes.
4. GV: Various answers.
5. QW: Why not send just T1 and T4 for accuracy?
6. GV: Following 802.1as for sending timestamp and timestamp difference, but will think about it - does not see a clear difference.
7. QW: Would prefer timestamp accuracy field to be 2 octets.
8. GV: One byte sufficient to express accuracy of +-20 nanoseconds.
9. General questions on timestamp accuracy.
10. GV: Will clarify timestamp accuracy in next presentation.
11. QW: Question on defined constants.
12. GV: Explanation of defined constants.
13. QW: Do we need to define those aspects of delay which are internal to an implementation?
14. GV: Explanation follows.
15. Various questions on delay components that occur before the antenna connector.
16. GV explains that separate components are required for flexibility – different antennas and encoding schemes.
17. QW: Do you need to break the preamble delay components into three?
18. GV: Explanation follows.
19. QW: What is meant by the sampling clock precision?
20. General consensus that it is jitter. Ganesh may change the name after referring to Kevin Stanton.
21. Question on how the information will be used.
22. Ganesh cannot answer as to how the SME will use the information. Refers to Thursday AM1 presentation by Kevin Stanton 802.1as for answers.
23. Question from the floor: How does the information get to the media application?
24. GV: The information does not go to the application. It is used by a different entity between PHY and application.
25. General discussion on how the system may work from application to application.
26. Question on whether this is necessary for 802.11 to handle.
27. GV: Yes, as it is part of an 802.1as system.
28. Discussion on 1 vs 10 nanosecond accuracy for timestamp counter unit field.
29. Discussion by Ganesh on removal of MIB dependencies pointed out by Qi Wang, and consequent changes. Timing measurement is now a standalone feature.
30. AT: What is the plan for this document for the rest of this week?
31. GV: The document is much better but needs more work. A revision is not planned to be ready by the end of the week.
32. AT: There is no point putting the current text into draft 4 if this will fail the letter ballot.
33. Ganesh agreed to change timestamp counter units to 10 nanoseconds and leave the timestamp accuracy field at 1 byte long.
34. EQ: 24 pages is a large piece of text to incorporate so it should be correct.
35. Discussion on accuracy test for timing sync feature.
36. QW: Question on necessity of preamble related delay components and the naming of the terms.
37. GV: Explanation why components necessary.
38. CH: Do you want to make a motion now?
38. Motion:
1. Move to adopt the comment resolutions for the Timing Measurement category comments indicated below and include the indicated text changes into the TGv draft.08-1011-05 (Timing measurement) – All accepted, counter and declined comments and normative text changes in 08-1229-02
2. Moved: Ganesh Venkatesan
3. Seconded: Emily Qi
4. Discussion: Why not do the motion tomorrow?
5. What is the plan for the other changes? – Ganesh to present tomorrow.
6. EQ: speaks for the motion as the text is a big improvement on the current draft.
7. GV: refers to Kevin Stanton’s presentation on Thursday and an advantage in synchronizing with what is to be presented there.
8. Result - 6/2/3 (For/Against/Abstain) Motion passes
39. Discussion on a rejection reason for CID 302. Chair to see if Jon Rosdahl can be present when the motion is moved.
40. Discussion moved on to CID 1274. Various technical reasons for rejection were discussed.
41. Recess at 21:30.
Wednesday November 12, 2008 AM1 Session, 08:00-10:00
42. Chair called the meeting to order at 08:05, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda, see 08/1200r3
43. Presentation by Darwin Engwer, (DE, Nortel Networks), 08-1294-00 Enhancing BSS Transition Management
1. DE: Presenting on behalf of Kenan Xu, Nortel
2. DE then presented 08-1295-01 Enhancing BSS Transition Management
3. 08-1295-01 shows the potential changes to the text
4. AT: If an AP does support BSS transistion but is unable when ADDTS to supply a candidate list, what is the fine grained behavior? There may be conditions under which the AP cannot always respond with a candidate list.
5. EQ: The text says it’s not mandatory.
6. AT: Is there language in clause 11 to say if the AP does not resources that it does not have to supply a candidate list?
7. Ali Raissinia (AR): Clause 10 language that a station shall transition must move to clause 11 and be turned into a ‘may’.
8. Kapil Sood (KS, Intel): How does the proposal add anything to the existing text, i.e. where tspec fails?
9. DE: Makes it a single atomic operation so it can’t be lost, and provides a candidate list showing where to go.
10. Kapil: but the STA can ask for a neighhood report within 10 ms
11. DE: But the enhanced BSS transition will be faster, tighter and more efficient.
12. JK: Proposal is based on the premise that the sta does not already have information from the tspec response so this is efficient for rare cases only. BSS transition is based on advice from the AP.
13. DE: Work with large numbers of handsets indicates it is not that rare.
14. EQ: This is an enhancement that optimizes BSS transitions.
15. KS: Would like to see more deterministic approach, i.e. in a heavily loaded system the information is not advice but is mandatory.
16. DE: That is good feedback.
17. AT: The actual BSS transition request frame has additional fields which are not included in the proposal, which are required for consistent and deterministic behavior.
18. DE: Good feedback.
44. Straw polls:
1. Do you agree that there is a need to streamline the BSS transition process as described in this presentation?
2. Yes/No/Abstain: 2/0/14
3. Do you agree that the approach in the second solution presented in this presentation should be included in the new revision of the 802.11v draft?
4. Yes/No/Abstain: 5/0/11
45. Motion
1. Move to adopt the comment resolutions for the Diagnostics category comment indicated below, and include the indicated changes into the TGv draft
2. CIDS 163,227
3. Moved: Allan Thomson
4. Seconded: Peter Ecclesine
5. Result: 7/0/7 (For/Against/Abstain) Motion passes.
46. Presentation by Qi Wang, Broadcom, 08-1327-02, Proposed Solutions to LB133 CIDS 1239 and 1257
1. Qi covered differences between r1 and r2.
2. No questions or comments.
47. CH: where are we with 1262?
1. AT: we need to continue the discussion
48. CH: lets move on to discuss 1378
49. Presentation by Darwin Enger, Nortel Networks, 08-1378-00 Improving Multicast Reliability
1. AR: Is this behavior dynamic in a way that an ap can accept/reject a request and is there a sync mechanism to move a sta between expecting the service and not expecting.
2. DE: yes it is very dynamic
3. AT: has this proposal changed since last presented?
4. DE: No, this is revisiting with highlighting different benefits.
5. AT: then the original concerns have not been met
6. DE: thought they had been.
7. EQ: people mostly concerned to hear the benefits
8. JK: Does not think it a beneficial proposal. Negatives – it’s a stop gap to address short comings of the multicast service which is the job of 802.11aa to improve. This proposal removes multicast. The idea of multicast is to improve efficiency. Current vendor specific provisions can already provide this feature. This points out problems in the implementation of multicast which will be masked by the proposal.
9. PE: Benefits relate mostly to running at 10 Mbps and less. Please solve the problems at low rates for television white space.
10. DE: fundamental problem is contention for the medium not the data rate.
11. HP: Does the AP need to wait for stations to wake in order to service stations?
12. DE: Yes.
13. EQ: Teardown is buffered. There is no specific text on when ap ceases service.
14. DE: gives examples of scenarios involving printers
15. KS: Speaks in support of proposal.
16. AT: responding to example, could be an application layer problem?
17. DE: yes
18. CH: do you want to make a motion?
19. DE: yes
50. Motion:
1. Move to adopt the comment resolutions for the general category comment indicated below and include the indicated text changes into the TGv draft. CID 269 – “Counter, “Incorporate the text changes indicated in 08-0050-03”
2. Moved Darwin Engwer
3. Seconded Emily Qi
4. No discussion
5. Result 6/2/8 (For/Against/Abstain) Motion passes
51. CH: What is the status of submissions to resolve the event comments?
1. AT: document is just posted (~9.30)
2. JK: There are two solutions to the same CIDs in r1 and r2 that need to be worked out.
3. CH: is that a request for a straw poll?
4. JK: yes but just before the vote
5. AT: It would be better to walk through r2 first
6. HP: In terms of the consumer of event reports, the collector of the info needs to correlate reports from different sources,i.e. in time – is that the requirement for UTC?
7. AT: yes
8. HP: The management console could do some of this?
9. AT: it’s a scaling question, i.e. distributed vs centralized
10. HP: issue with UTC vs timestamp, for the proposal a MAC has to understand leap years etc. In addition the UTC info sent by the AP has the same requirement for update when sent over the air as the TSF. STA also has processing to do.
11. AT: Hhow do you solve the problem
12. HP: In the advertisement provide an offset between UTC and TSF when it was zero which saves the STA from doing date calculations and the back end does the work.
13. HP: The UTC offset is always related to TSF zero. The sta includes both tsf and offset when it reports. Initialising is a problem.
14. AT: That is the benefit of putting UTC in the beacon, but it sounds like a good proposal
15. JK: valid proposal. The timestamping has only one time base which is good. It works for all cases seen at the moment.
16. DE: 11p has an mlme interface to make adjustments to the tsf which need to be considered
17. HP: the UTC offset can be adjusted. TSF should not be changed as that would have other effects. Sta needs the UTC offset with TSF early to cope with BSS transition – needs to go in beacons and probe responses.
18. AT: started reworking proposal to incorporate feedback so we can come up with a proposal. Goal is to post the document today, before PM2, in time to vote tomorrow.
52. Meeting recessed at 10:00
Wednesday November 12, 2008 PM1 Session, 13:30-15:30
53. Chair called the meeting to order at 16:00, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
2. Chair reviewed the agenda, see 08/1200r4
54. Presentation by Chen Zhang, (CZ, China Mobile), 08-1321-00 Table of inferential APs using same channel
1. AT: Have you considered the neighbour mib in 11k?
2. CZ: We have considered but not enough information.
3. AT: The neighbor mib might be better extended rather than having a new table since both the new table and neighbor table need constant updating.
4. GS: Is the idea to have a historical record over time? Time is not in the neighbor table so you won’t have a time based log. If the idea is a log over a period of time then this is a different idea.
5. CZ: Table updated periodically and queried periodically, not a log.
6. QW: We already have neighbor table, how is this difference? Who decides that interference is happening?
7. CZ: The current mib does not cater for APs not belonging to different operator. An AP belonging to a different operator is an interfering AP on same channel. See slide 5 of presentation.
8. JK: The neighbor report in K does not cater for this, e.g. overlapping ESS is not covered. However the AP report in 11k gives this exact information. The beacon measurement can solve this rf problem. There may be a way to augment the neighbor report with geographic information to indicate where interference is occurring, particularly if other AP is using geographical information.
9. CZ: Location information may not be correct. RF information will always be right.
10. JK: you can rely on beacon report.
11. AT: question on use case – is there an assumption of a higher layer management function that will effect change to reduce interference – correct?
12. CZ: We can use the information to find which operator an AP belongs to so we can alleviate interference manually or automatically.
13. AT: Sounds like a very manual operation which may not solve the problem.
14. CZ: Without this information we must send someone to measure the problem on-site.
15. MH: Please clarify that there is no intention to provide new information to clients or use them, this is only to gather information from APs for human manager to act on.
16. RD: Please define your concept of interference, is it 100 mw access points or high powered p2p bridges?
17. CZ: see definition on slide 5
18. RD: then this is based on overlapping APs. The 802.11 protocol is designed for the overlapping case. On slide 8 how do you have the knowledge to filter, i.e. whether APs are owned by the operator or not. This is not in the standard.
19. GS: OBSS is not interference, it just reduces bandwidth. It’s a dynamic situation and dynamic frequency selection might do a better job for this problem. Move to 5GHz. Information will become stale.
20. CZ: OBSS management is necessary in applications.
21. GS: some sort of DFS is preferred
55. Straw poll
1. Do you think it meaningful to add such kind of measurement and reporting parameters to keep the network more controllable?
2. Yes 2, No 2, Abstain 19
56. Presentation by Chen Zhang, China Mobile, 08-1322-00 Times of refused associated requests by the restriction of user limits
1. AT: on Slide 6 you don’t say where this MIB object is contained. Is this a single value for all BSSs in an AP or one value for the whole AP?
2. CZ: single value per BSS
3. AT: your proposal doesn’t say which table it will be in. it needs to be added to a BSSID related table. Is your attention that is just association or assoc and dot1x authentication.
4. CZ: just association with not relation to security
5. MH: I don’t see anything for refusal due to admitted traffic streams. Is that correct?
6. CZ: Not related to QOS refusals.
7. MH: there’s an assumption that when AP is full it refuses further associations regardless of traffic load presented
8. CZ: correct
9. MH: that seems too simplistic. You need to consider admitted QOS traffic streams
10. CZ: using number of associations is simple and effective
11. CH: on slide 5 it shows it’s a simple average
12. QW: Is there a time unit? Hour, day?
13. CZ: We assume a period of less than one hour. 5 minutes is very good.
14. QW: So you track a sliding window and use histograms etc. How do you use the information?
15. CZ: explains how in general
16. RD: This is a simple method of load balancing is it not?
17. CZ: No it is not designed to prevent associations.
18. QW: is this for traffic analysis or load balancing?
19. CH: go to slide 5. Looks like the intent is to gather information only and process off-line
20. RD: But slide 7 indicates that the number is used to limit associations.
21. CH: No the counter is incremented when association is refused.
22. MH: then load balancing must be on
23. CZ: but there may be other reasons for refusal as well
24. JK: there are other measures available via snmp which relate to station mac addresses which may suit the problem with respect to estimation. Load balancing in the presentation confuses things. Take out load balancing and count refusals due to capacity constraints.
25. GS: seems a reasonable submission deserving of support. Agree with Joe’s comments on terminology.
26. RD: Speaking against it due to the confusion caused by terminology.
57. Straw poll:
1. Do you think it meaningful to put the Dot11NumRefusedAssociatedForUserLimitcounter into the MIB to facilitate some service and network quality?
2. 5/2/15 (yes/no/abstain)
58. Presentation by MM Montemurro, (MM, Research in Motion), Prioritized Action Frames
1. GS: Likes the idea. Is it more or less priority than a normal mgmt frame, e.g. ACVO?
2. MM: It is flexible.
3. HP: Management frames currently go at ACVO. This creates a frame type that can go at a different priority.
4. GS: Can we make it mandatory?
5. PE: Make it an alternative sub-type number if possible.
6. MM: We are flexible.
7. AT: This new frame is only for events and diagnostics?
8. MM: yes
9. AT: So the intention is that these frames are treated as lower priority than other mgmt frames?
10. MM: it allows this.
11. AT: The reason for introducing was to protect the sta from requests.
12. HP: No the reason is to protect the medium, i.e. voice calls or similar, from large volumes of event logs etc sent at ACVO. The sta echoes the priority in the request.
13. EQ: Why is this being dealt with by 11v? Also agrees that different sub-type should be chosen. On page 4 use of prioritized action frame also needs changes to table v36 in draft 3.0. WNM action field values.
14. MM: action field values should not need to change.
15. EQ: WNM uses a particular subtype
16. MM: you want some additional text? Refer to 7.19a, the frame body does not change.
17. MH: I haven’t seen how this affects EDCA values therefore these frames are still sent at ACVO?
18. MM: I didn’t find anywhere this can be added.
19. Mark: no there are explicit statements that need to be changed that I can identify. Also need text to explain how this interacts with admission control.
20. MM: okay, assistance welcomed.
21. Andrew: purpose is to protect medium, however there seem to be many exceptions. You are not solving the entire problem. It would be better to look at a general solution in a different group.
22. MM: there are tradeoffs. Events and diagnostics should be fixed first since they are known problems.
23. Andrew Myles (Cisco): we should take time to solve the larger problem.
24. HP: wrt 802.11w the replay counter text needs to be sorted out.
25. AM: this is still the wrong group to solve the general problem involving 11e, 11w, 11v and 11k etc
26. RD: in favour of the submission. Events and diagnostics need to be taken care of within 11v now.
27. AR: not sure we need a sub-type.
28. MM: In July a subtype was voted as the only viable option
29. HP: a subtype is required to add the QOS header to allow 11w to work
30. AR: table 7.4 needs clarification
31. Nancy Can Winget (NCW, Cisco): The rule is that events and diagnostics must be prioritized - are other management frames precluded? What is the broader implication?
32. HP – no
33. NCW : Concerned there may be hardware implications and that there may be changes to 11w
34. JK: supports general idea of prioritized management frames. We should make this change in 11v and other changes go to TGmb.
35. MH: agrees with Joe K. Action frames have special treatment under power save that needs to be considered.
36. HP: What is amendment ordering?
37. CH: v follows w.
38. PE: mb follows existing pars. Everything published before mb gets rolled into mb.
39. DH: Question to CH about timeline.
40. CH: 11v due July 2010.
41. DH: timing vs TGmb is tight
59. Motion:
1. Move to adopt the comment resolutions for the general category comments indicated below, and include the indicated text changes into the TGv draft;CDs 251-254 etc
2. Discussion:
3. Emily: speaking against, not convinced 11v correct group. Wrong sub-type value and other changes need to be made, e.g. some wrong clauses.
4. MM: speaking for, changes required are minor.
5. Moved: MM Montemurro
6. Seconded: Henry Ptasinski
7. Result: 11/6/4 (For/Against/Abstain) Motion fails
60. Motion
1. Move to adopt the comment resolutions for the general category comments indicated below, and include the indicated text changes into the TGv draft:
1. CIDS 1239, 1257 – counter “incorporate text changes in 08-1327-02”
2. Moved: Qi Wang
3. Seconded: Ganesh Venkatesan
4. Result: 16/0/4 (For/Against/Abstain) Motion passes
61. Motion:
1. Move to adopt the comment resolutions for the Event category comments indicated below, and include the indicated text changes into the TGv draft:CIDs 1227, 1328 – Counter - incorporate text changes in 08-1391-01
2. Moved: Allan Thomson
3. Seconded: Qi Wang
1. Discussion:
2. Joe K: the group should review the document
3. CH: the document was on the server for 4 hours and the motion is in order.
4. Joe K: I have comments. The presentation is well done with good provisions. Why is the timestamp in the beacon and probe responses?
5. HP: stations may be able to use it for setting time and other purposes and may need it immediately on BSS transition
6. Joe K: Why is accuracy in beacons etc and not in reports in case of varying accuracy across different APs?
7. HP: Across an ESS we assume the time base will be consistent with reasonable accuracy.
8. Roger: Important to differentiate declarations of time with different accuracy, e.g. GPS vs other clocks.
9. DH: Would prefer use of ESS time rather than UTC.
10. HP: UTC is convenient and well recognized and global to the ESS.
11. AT: UTC convenient choice.
4. Result: 15/0/5 (For/Against/Abstain) Motion passes.
62. Motion:
1. Move to adopt text changes in 00-1371-00 into the TGv draft
2. Moved: Ganesh Venkatesa
3. Seconded: Qi Wang
4. Discussion:
5. Ali: Is this mandatory or optional?
6. GV: optional
7. Ali: are you serious about 10 ns accuracy
8. GV: yes
9. Ali: you mean accuracy or resolution
10. GV: it’s the unit, we can talk offline
11. Ali: ok
12. Result: 12/1/6 (For/Against/Abstain) Motion passes
63. Recess at 15:30
Thurssday November 13, 2008 PM2 Session, 16:00-18:00
64. Chair called the meeting to order at 16:00, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.
1. Chair reviewed the agenda for this timeslot
2. Chair reviewed the agenda, see 08/1200r7
65. Discussion on CID-251 (see 08-1200-07)
1. RD: If motion simply declined then would agree, but does not agree on first bullet item in 1200-07 for motion on CID251.
2. CH: bullet points reflect feedback from all group to commenters.
3. Mark: Change sentence to read: “Concerns that were raised include
4. Roger: Would like to be diplomatic
5. HP: These points are in the minutes, prefer to refer to minutes
6. Roger: agree
7. AT: agree
8. George Buimiller (GB, RIM): Putting something outside of par into motion: should that be done? However the minutes are a record of what happened so that is a reasonable approach.
9. General agreement on referring to the decline reasons being in the minutes.
10. AT: If commenters are fine with references to the minutes then that is okay – refer to session minutes – and if that is fine with them that is fine with me.
11. BM: This is how comments are normally dealt with before passing LB. These comments deal with a specific problem and the decline reason should be specific.
12. AT: Believes technical reasons are captured in the minutes.
13. BM: this method of operation will only be acceptable until we achieve letter ballot
14. MM: As a former secretary is is okay to refer to the minutes.
15. Mark: The case is that we didn’t like the proposed resolution.
16. AT: Didn’t we say referring to minutes was okay?
17. EQ: This proposal only addresses part of the problem.
18. MM: The commenters need sufficient feedback on how to address the feedback
19. JK: Should also say commenter is acknowledged and encouraged to present at the next meeting.
66. Motion
1. Move to adopt comment resolutions for CID251 as declined
2. Moved: Mark Hamilton
3. Seconded: Joe Kwak
4. Results: 3-1-12 (For/Against/Abstain) motion passes
67. Motion
1. Move to adopt the comment resolutions for CID 1274 as declined
2. No discussion
3. Moved: Allan Thomson
4. Seconded: Emily Qi
5. Result: 7-1-8 (For/Against/Abstain) motion passes
68. Motion
1. Move to adopt the comment resolutions for the Co-located Interference category comments indicated below, and include the indicated text changes into the TGv draft.
2. CID 302 – Declined, “The TG adopted the collocated interference capability to enable the STA to provide an indication of collocated interference that may be present, and the TG believes that this capability is complete and sufficient. The need for additional specification of transmit inhibition is not clear. The examples cited in 1010-03 include the case when ACK is used; however when ACK is used, there is no difference between thereceive and transmit interference. Another example cited is applicability to broadcast/multicast traffic. However, with MC/BC – there is no need for the AP to know that transmitter is inhibited, unless all stations would have the same exact inhibitionschedule. Another example cited is when delayed ACK and Block ACK are used. However, Delayed ACK, Regular Block ACK are still sent, or are sent at a pre-defined delay time. Not clear how the AP can schedule to use the information provided in the proposed additional bit(s). In addition, distinguishing between RX/TX provides an even higher layer of granularity, creating a false expectation of frame scheduling on the part of the user. ”CIDs 303 through 308 – “ See CID 302”
3. Moved: Qi Wang
4. Seconded: Emily Qi
5. Result: 8-2-6 (For/Against/Abstain) Motion passes
69. 16-25 Presentation by Joe Kwak, InterDigital Communications, 08-1396-00 LB133: Normative Text Update for Annex Q
1. RD: Transmitter power p87 line 27-28. Why can’t I find this on Joe’s document? (found on a different line)
2. JK: This is cut and paste into a mib. The description transported with MIB values so it is important. We should update the MIB as we improve the other parts of the text.
70. Motion
1. Move to adopt the text changes in 11-08-1396-00-000v-normative-text-annexq-update.pdfinto the TGv draft.
2. No discussion
3. Moved: Joe Kwak
4. Seconded: Allan Thomson
5. Result: 10-0-3 (For/Against/Abstain) motion passes
71. Adhoc dates discussion:
1. JK: When will LB start and end?
2. CH: 17-19 Nov and would go out for 30 days
3. PE: 40? For recirc?
4. CH: No, 30. LB then comes back end of week before Christmas, say 18 Dec. Prefer teleconf in Jan, followed by 802.11 meeting with adhoc afterwards.
5. Peter E: not expecting to recirc out of Jan?
6. CH: plan is to recirc out of March
7. AT: Who will be at the adhoc? Concerned about having it.
8. CH: If we scheduling an adhoc it requires planning.
9. QW: Prefer to work offline.
10. AT: Travel is expensive and constrained currently. The adhoc may not be justified if it requires travel
11. CH: Are you volunteering to host?
12. AT No, just questioning the value.
13. CH: well we can schedule teleconferences but I would like to plan an adhoc due to 30 day advance requirement and potential overlap with wi-fi meeting.
72. Straw Poll
1. TGv should authorize an adhoc in Feb 2009
2. Discussion:
3. Roger: if LB passes would attend adhoc but probably not otherwise
4. Dorothy: would like to organize the adhoc and confirm or cancel in January
1. Yes: 5
2. No: 0
3. Abstain: 13
73. Motion
1. Move to authorize a TGv Ad-hoc
2. Feb 16-18, 2009 (Mon-Weds), in San Jose area, host tbd
3. Mover: Joe Kwak
4. Seconder: Fujio Watanabe
5. Result: 3-1-12 (For/Against/Abstain) Motion passes
74. Motion
1. Motion to authorize TGv teleconferences Jan 6, 13, Feb 3, 10, 17, Amr 3 2009
2. Mover: Emily Qi
3. Seconder: Fujio Watanabe
4. Discussion
1. JK: One date is when adhoc is on
2. CH: one or other conference will be cancelled
5. Result: 7-0-7(For/Against/Abstain) Motion passes
75. Discussion on waiting 22 minutes until four hour rule for next motion has been met
1. P: If not a draft you can vote now
2. BM: you are changing a draft and must wait four hours
3. CH: not worth the risk, wait another 22 minutes, take a 15 minute recess
76. 17:23 Chair: Meeting called back to order
77. Motion
1. Move
2. To adopt TGv Draft 3.04 as the TGv draft,
3. To instruct the editor to renumber TGv Draft 3.04 as Draft 4.0 and
4. To request the 802.11 WG chair to conduct a 30-day Letter Ballot on TGv Draft D4.0, asking the question “Should TGv Draft 4.0 be forwarded to Sponsor Ballot?”
5. Mover: Emily Qi
6. Seconder: Allan Thomson
7. Discussion:
8. Roger Durand RIM: I will vote no in letter ballot but will abstain in this motion. If we continue to fail then we should consider limiting new elements and presentations so that we can finish 11v. This may require change to PAR that I will propose if the LB fails the next vote.
9. Question from floor: Is it 30 or 40 days for LB
10. CH: 30 is correct
11. Result: 11-0-5 (For/Against/Abstain) Motion passes
78. No further business. Meeting adjourned 17:28.
References:
-----------------------
Abstract
This document contains the meeting minutes from the Dallas November 10-14, 2008 TGv meeting.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.