doc.: IEEE 802.11-08/1353r0 · Web viewYes -10, No – 6, Abstain – 6 CH: Reviewed...

November 2008 doc.: IEEE 802.11-08/1353r0

IEEE P802.11Wireless LANs

November 2008 Meeting Notes

Date: 2008-11-19

Author(s):Name Affiliation Address Phone email

David Goodall G2 Microsystems

24 Campbell StHaymarket NSW 2000

Australia612 9213 2529 david.goodall@g2mi

crosystems.com

Dorothy Stanley Aruba Networks 1322 Crossman Ave

Sunnyvale, CA 94089 +1 630-363-1390 [email protected]

Submission page 1 Dorothy Stanley (Aruba Networks)

AbstractThis document contains the meeting minutes from the Dallas November 10-14, 2008 TGv meeting.

mailto:[email protected]





Monday November 10, 2008 PM2 Session – 16:00 – 18:00

1.0 Chair (CH: Dorothy Stanley, Aruba Networks) called the meeting to order at 16:00, welcomed participants and reminded participants to record their attendance.

1.1 CH:Reviewed the patent policy slides1.2 CH: Asked for essential patents/patent holders, per patent slide instructions. None brought

forward.1.3 Agenda is in 08-1200-00, on the server1.4 CH:Reviewed the status of the group1.5 CH, membersAdjustements to the agenda, per member requests for times for their

presentations. Updates will be posted as 08-1200-01

2.0 CH: Is there any objection to adopting the Agenda shown? No objection, adopted by unanimous consent (Motion 1)

3.0 Presentation by Joe Kwak (JK,Interdigital) 08-1262-013.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.

3.2 CH: Thank you. Are there questions for Joe?3.3 Qi Wang (QW, Broadcom) – What happens if the AP does not have the value, why is even a

short field provided?3.4 JK – Needed for parsing the field values.3.5 David Hunter (DH, Panasonic) – Is this an ESS wide value – similar to mobility domain, is

this UTC domain?3.6 JK – Logs are not cancelled upon a transition to a BSS in the same ESS.3.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.

3.8 JK – There are many standards documents that define UTC formats, none meet our needs. Term has a general English meaning.

3.9 CH: No more questions seen. Suggest hearing next presentation on same topic, then discuss way forward.

4.0 Presentation by Allan Thomson (AT, Cisco Systems) 08-1309-004.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

4.2 CH: Thank you. Are there questions for Allan?4.3 DH – Can the field be included in every Beacon frame?4.4 AT – Yes, not prohibited, but concerned with beacon bloat, don’t require the field in every

Beacon.4.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.

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

4.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?

4.8 AT – Not replacing the TSF, rather in addition to it. The TGv event reporting feature.



4.9 JK - No claim of synchronization, just a reference point.

5.0 Straw poll 1 – 5.1 UTC Time availability should be General/Local/Abstain. 5.2 Result: General – 5, Local – 6, Abstain – 12

6.0 Presentation by Jing Zhu (JZ, Intel Corporation) 08-1010-036.1 JZ- reviews the document, and the 3 alternate wordings proposed.6.2 Jon Rosdahl (JR, CSR) – Support this idea, select one of the wordings, polish language going

forward.6.3 PE –Language in option 2 is not as direct as that in option 1.6.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.

6.5 JR – Believe the capability is beneficial, implementation specific application. Identify the type of interference, focus on the definition, rather than implementation.

6.6 JK – This isn’t a big deal, proliferation of wireless devices means that collocated interference exists.

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

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

6.9 PE– A device that can’t transmit or is not receiving is not compliant with the standard.6.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. 6.11 JR – Meets applications today and planning of transmissions is happening today.6.12 QW Please bring an example.6.13 AT – Have seen no info on how this works.

7.0 Straw Poll 2– Prefer the option 1, option 2, option 3, None, Abstain text in 1010-037.1 Option 1 – 3, Option 2 – 0, Option 3 – 0, None – 1, Abstain – 18

8.0 Straw Poll 3 – The approach in 1010 should be added to the TGv draft 8.1 Yes -10, No – 6, Abstain – 6

9.0 CH: Reviewed the agenda, plan for the upcoming evening session.

10.0 Recess at 18:00



Monday November 10, 2008 Evening Session, 19:30-21:30

11.0 Chair called the meeting to order at 19:40, welcomed participants, reminded participants of the Patent policy and reminded participants to record their attendance.

11.1 Chair reviewed the agenda for this timeslot

12.0 Presentation by Ganesh Venkatesan( GV, Intel Corporation) 802.11-08/0891-r1 Timing Measurement

12.1 GV – Goes through presentation. Slide 14 needs correction +- 20 nanoseconds at start of diagram

12.2 Kapil Sood (KS, Intel Corportation) – question clarifying retransmissions. Protocol requires ACKs to complete.

12.3 Jim Petronovich, (JP, Visat): requesting a submission explaining how the timing tolerance can be met.

12.4 QW – similar concern on accuracy assumptions with respect to manufacturing variations etc.

12.5 Neil Warren, (NW, Apple) – tolerance should be attainable.12.6 JP - concerns about multipath variation12.7 Kevin Stantan, (KSt, Intel Corporation) – addresses concerns on multipath12.8 JP - would still like a submission12.9 GV - refers Jim to existing submission 1229-R112.10 KS – joint 802.11AA/802.1 meeting Thursday 8-10 top down presentation on this topic12.11 QW - asks for information to be sent to 11v reflector, Ganesh to do this.12.12 GS – slide 6 why use the ACK for the timing measurement?12.13 GV– gives quickest feedback

13.0 20.20 Presentation by Qi Wang< Broadcom Corporation, 802.11-08/1327-r1 resolutions to LB133 CID 1239, 1257

13.1 QW - reviews the current document13.2 EQ – question on 11.2.1.13 dot11WirelessManagementImplemented – what happens if

false13.3 GV – commented on an umbrella statement for the negative case13.4 AT – okay with text13.5 EQ – thinks first sentence not required13.6 Bill Marshall (BM, AT&T) - thinks first sentence not required, keep mandatory

statements but not optional ones.13.7 Matthew Fisher (MF, Broadcom) - No normative word in sentence13.8 MH – TIM broadcast is optional and a sta that implements TIM broadcast shall set the

MIB attribute to true. 13.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

13.10 MF – Second sentence does not follow IEEE style guide.13.11 MH – problem with ‘supports’13.12 MH – recommends TIM broadcast STA, proxy ARP STA etc to get around problem13.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.13.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.

13.15 AT – STA must implement mandatory features in order to implement optional features or the entire specification must be revised.

13.16 Jouni Malinen (JM, Atheros) – leave the PICs to define optional and mandatory features.



13.17 QW – 11v has two MIB variables 13.18 Brian Hart, (BH, Cisco) – in favour of ‘disallows’13.19 Joshua Zhou (JZ, Atheros) – why are we disallowing features?13.20 EQ– then make all features optional13.21 BM – not in favour of disallowing in case it causes problems in other areas of the spec13.22 AT – 11.20.1 text: When dot11MgmtOptionTIMBroadcastImplemented is true,

dot11WirelessManagementImplemented shall be true.13.23 Final Rewrite?

13.23.1 The implementation of TIM Broadcast is optional for a WNM STA13.23.2 A STA that implements TIM Broadcast has the MIB attribute

dot11MgmtOptionTIMBroadcastImplemented set to true.13.23.3 When dot11MgmtOptionTIMBroadcastImplemented is true,

dot11WirelessManagementImplemented shall be true.13.24 AT – suggests similar treatment for Event request and event report as for TIM broadcast13.25 Daniel Borges (DB, Apple) – how does this reflect the PICs?13.26 CH – it is the same as the PICS13.27 AT – comment on PICS - WNM 2 has lost consistency13.28 QW – will check13.29 Discussion on various aspects of the PICs.

14.0 Motion :14.1 Motion to approve minutes from September and teleconference meetings to

November. 14.2 Mover: Ganesh Venkatesan14.3 Seconder: Emily Qi14.4 Result: Unanimous

15.0 Motion 15.1 Motion to adopt TGv draft 3.02 as current TGv draft. 15.2 Mover: Allan Thomson15.3 Seconder: Ganesh Venkatesan15.4 Result: Unanimous

16.0 Motion :16.1 Motion to adopt changes in 1197-04 into TGv d3.02. 16.2 Moved: Allan Thomson16.3 Seconded: Emily Qi16.4 Result- 8-0-3 Passes

17.0 Recess until 10:30 Tuesday

Tuesday November 11, 2008 Morning AM2 Session, 10:30-12:30


18.1 Chair reviewed the agenda for this timeslot18.2 Chair reviewed the agenda, see 08/1200r118.3 Management frame priority moved to Wed PM1

18.3.1 AT: Objection to move to Wed PM1 based on experts being available for this time slot.

18.3.2 CH:: The presenter wants to move to Wed PM118.3.3 Mike Montemurro (MM, RIM): confirmed, request move to Wed PM118.3.4 AT - ok



18.3.5 CH: 08-1321 and 08-1322 also moved to Wed PM118.3.6 BM: 08-0419-R3, 1059-R1 ready for discussion Tue PM2, documents are on the

server18.3.7 CH: called attention to update of timing sync normative text 08/1229-01

19.0 Presentation by Allan Thomson, Cisco - 08-1284 Additional TIM CIDs19.1 MH: Why is normative text in clause 7?19.2 AT: This is also captured in clause 1119.3 Discussion on changes in clause 11.

20.0 Presentation by Allan Thomson, Cisco - 1013-r6 Additional Diagnostics Edits20.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.

20.2 AT Table v16 does not cater for multiple antenna types.20.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 etc20.4 CH: queried if normative references still required.20.5 AT - Confirmed normative references no longer required.20.6 Peter Ecclesine (PE, Cisco Systems): confirmed normative refs are in 802.11u.

21.0 Presentation by Allan Thomson, Cisco - 08/1282-r0 Collocated Device Diagnostic21.1 AT: New collocated device types and table device added.21.2 AT - Changes to 11.20.3.3 Manufacturer Information STA Report similar to changes in

1013-r6.21.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.

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

21.5 PE: Prefers definition in 3 and change to 11.20.3.3 definition.21.6 QW: Querying whether interfering device is on or off. Referred to Definition in 3 where

it is defines as either on or off.21.7 AT: Responded to definition of “device type” with different options.21.8 EQ: Would prefer a definition that distinguishes devices capable of interfering from other

devices like printers etc. Will take discussion off-line. 21.9 PE: referred to 802.21 as origin of definitions.21.10 MM: discussion on the table v13a which is to be included in 11v: definitions may need

work21.11 PE: described background of how 802.21 arrived at the definitions in table v13a.21.12 AT: Question to MM: If you have additional concerns/changes please discuss offline.

22.0 Motion to adopt changes in 11-08-1284-00-000v-additional-TIM-CIDS into TGv draft22.1 Moved: Allan Thompson22.2 Seconded: Emily Qi22.3 See no discussion on motion.22.4 Result: Passed 13-0-4 (for-against-abstain).

23.0 CH: summarized afternoon (PM2) agenda.23.1 Attendance log reminder.

24.0 Recess at 11.15am.



Tuesday November 11, 2008 Afternoon PM2 Session, 16:00-18:00


25.1 Chair reviewed the agenda for this timeslot25.2 Chair reviewed the agenda, see 08/1200r2.

26.0 Presentation by Bill Marshall, ATT, 08-0419r3 Access Point Collaboration Normative Text26.1 BM: 802.11k spectrum management will be in cell phones.26.2 Henry Ptasinski (HP, Broadcom): Slide 12 please explain graph of jitter increases with #

APs26.3 BM: Explanation26.4 HP: Querying load on stations as being outside normal operating range.26.5 BM: Will need to re-check original results26.6 HP: Slide 11 – more APs makes things worse – please clarify the comparison of APs to

APs26.7 BM: Explanation26.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.26.9 BM: disagrees.26.10 HP: Do you have any figures from the same testbed with the AP collaboration

mechanism26.11 BM: No, the results are simulated.26.12 Allan: Slide 14 How many APs are in the simulation?26.13 BM: Two APs26.14 AT: Alex previously said that AP collaboration worked for two APs but not more. Do

you have any results for for APs?26.15 BM: In ATT experience the problem can be reduced to a pairwise problem.26.16 AT: Slide 13 – In reality sync between Aps is hard to attain.26.17 BM: Sync is up to the network manager.26.18 AT: Questions whether this can be done.26.19 GS: Slide 11 – How does the traffic decrease with the increasing number of APs?26.20 BM: Time lost to backoffs causes traffic to decrease.26.21 GS: Not convinced.26.22 DH: Stations will respect the NAV and go quiet.26.23 BM: Main reason is the collision between APs.26.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?26.25 BM: That case is not included.26.26 HP: But that is the common case.26.27 Comment - co-author -: The solution and cases are for enterprise deployment.26.28 HP: It still appears unrealistic and would like to see more cases.26.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?26.30 BM: Thinks this is downlink TCP/IP traffic but will check.26.31 Graham: Slide 14 what is YANs26.32 BM: Yet another network simulator.26.33 GS: Question on scheduling methodology26.34 BM: Equal scheduling on both sides.26.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.26.36 BM: It’s synchronous in the beacons until it occurs.26.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.



26.38 HP: Wrt Peter E’s question on immediate channel change, channel change must be asynchronous right?

26.39 BM: Yes26.40 PE: But the language prohibits this.26.41 HP: yes26.42 PE: Once the suppression interval starts the AP is stuck there.26.43 BM: yes but this is not a problem because it is the same as radar detection case.26.44 HP: The AP needs to be able to send traffic if it must during any quiet period.26.45 BM: It can do this.26.46 PE: That is what is required.26.47 BM: Text is in the base.26.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.0 Motion 27.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 27.1.1 resolve CID 1274, as “counter”, with a comment resolution of “Incorporate

text changes in 08-0419-03” and 27.1.2 resolve CIDs 400, 1404, 1411 as “counter”, with a comment resolution of

“see CID 1274”27.2 Moved: Bill Marshall27.3 Seconded: Joe Kwak27.4 Result 5-7-8 Motion fails

28.0 17.05 Presentation by Allan Thomson, Cisco, 08-1283 r1 Diagnostic Device Type normative text

28.1 AT: explanation of the changes and the reasons.28.2 HP: URL is included to the WFA web site. How does that fit IEEE style guide?28.3 PE: Put the URL in a foot note.28.4 General agreement on use of foot-note.28.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?28.6 AT: Wants to include the WFA device types as is. The table is required because the WFA

does not include numerical constants.28.7 QW: You need a sentence to say that devices include 802.11. Additional comments on

two device types.28.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.28.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.28.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.28.11 EQ: Why mention WFA code category? 28.12 HP: With respect to URLs 11v need to check use of URLs before incorporating in the

base standard.28.13 PE: refers to submission 1045 which gives guidelines to editors.28.14 AT: wishes to make the motion and incorporate any changes as editorial changes.

29.0 Motion 29.1 Move to adopt the comment resolutions for the Diagnostics category comments

indicated below, and include the indicated text changes into the TGv draft.29.1.1 CID 163, Counter, “Incorporate the text changes indicated in 08-1283-01”



29.2 Moved: Allan Thomson29.3 Seconded: Brian Hart29.4 Result 14-4-3 Motion passes

30.0 Motion 30.1 Move to adopt the indicated text changes in 11-08-1013-07-000v-Additional-

Diagnostic Edits into the TGv draft.30.2 Moved: Allan Thomson30.3 Seconded: Emily Qi30.4 Result 11-0-7 passes

31.0 Discussion on 1282r1 Allan Thomson (Cisco Systems)31.1 AT reviews text and changes.31.2 GS: On Table v13a – is it too late to add DECT?31.3 Peter E: for which country?31.4 GS: Japan31.5 AT: It’s not a closed list and can go in later31.6 EQ: Define Zigbee, Bluetooth etc. Can we add Wi-Max31.7 PE: Would rather add 802.16 as a catchall and other catchalls.31.8 AT: Then we should make the edits now.31.9 CH: Is that what you want to do?31.10 PE: What does the group want to do?31.11 AT: We will modify, repost it and vote tomorrow.

32.0 Motion 32.1 Move to adopt the indicated text changes into the TGv draft:

32.1.1 In 11.20.3, change from 32.1.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.

32.1.3 to32.1.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].

32.2 Moved: Allan Thomson32.3 Seconded: Dave Stephenson32.4 Result: 7/0/12 (For/Against/Abstain) Motion passes.

33.0 Motion33.1 Move to adopt the comment resolutions for the Traffic Generation category

comment indicated below:33.2 CID 73 – Declined, “Incorporate the resolution in 11-0801-02, and add “The

commenter is invited to submit additional clarifying text”33.3 Moved: Fujio Watanabe33.4 Seconded: Emily Qi33.5 Result Unanimous



34.0 Presentation by Allan Thomson, Cisco, 08-1262 r1 34.1 AT presents the redlined changes in the document.34.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.

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

34.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?

34.5 JK: Request cancelled means that the report is not sent. Logs are not destroyed on BSS transition but reports are cancelled.

34.6 QW: Why send a future AP a report with logs that were started by a previous AP.34.7 JK: The transition log is important and required.

35.0 Recess at 16.00.

Tuesday November 11, 2008 Evening Session, 19:30-21:30


36.1 Chair reviewed the agenda for this timeslot36.2 Chair reviewed the agenda, see 08/1200r2

37.0 19.35 Presentation by Ganesh Venkatesan, Intel, 08-1229-02 Normative Text for D3.02 Timing Measurement

37.1 QW: Section 7.4.11.23. Size of timestamp field?37.2 Ganesh: The timestamp field is 4 bytes due to size of time of departure timestamp size37.3 QW: Why not use TSF plus another 2 bytes for resolution? Other general questions about

field sizes.37.4 GV: Various answers.37.5 QW: Why not send just T1 and T4 for accuracy?37.6 GV: Following 802.1as for sending timestamp and timestamp difference, but will think

about it - does not see a clear difference.37.7 QW: Would prefer timestamp accuracy field to be 2 octets.37.8 GV: One byte sufficient to express accuracy of +-20 nanoseconds.37.9 General questions on timestamp accuracy.37.10 GV: Will clarify timestamp accuracy in next presentation.37.11 QW: Question on defined constants.37.12 GV: Explanation of defined constants.37.13 QW: Do we need to define those aspects of delay which are internal to an

implementation?37.14 GV: Explanation follows.37.15 Various questions on delay components that occur before the antenna connector. 37.16 GV explains that separate components are required for flexibility – different antennas and

encoding schemes.37.17 QW: Do you need to break the preamble delay components into three?37.18 GV: Explanation follows.37.19 QW: What is meant by the sampling clock precision?37.20 General consensus that it is jitter. Ganesh may change the name after referring to Kevin

Stanton.37.21 Question on how the information will be used.37.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.37.23 Question from the floor: How does the information get to the media application?



37.24 GV: The information does not go to the application. It is used by a different entity between PHY and application.

37.25 General discussion on how the system may work from application to application.37.26 Question on whether this is necessary for 802.11 to handle.37.27 GV: Yes, as it is part of an 802.1as system.37.28 Discussion on 1 vs 10 nanosecond accuracy for timestamp counter unit field.37.29 Discussion by Ganesh on removal of MIB dependencies pointed out by Qi Wang, and

consequent changes. Timing measurement is now a standalone feature.37.30 AT: What is the plan for this document for the rest of this week?37.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.37.32 AT: There is no point putting the current text into draft 4 if this will fail the letter ballot.37.33 Ganesh agreed to change timestamp counter units to 10 nanoseconds and leave the

timestamp accuracy field at 1 byte long.37.34 EQ: 24 pages is a large piece of text to incorporate so it should be correct.37.35 Discussion on accuracy test for timing sync feature.37.36 QW: Question on necessity of preamble related delay components and the naming of the

terms.37.37 GV: Explanation why components necessary.37.38 CH: Do you want to make a motion now?

38.0 Motion: 38.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

38.2 Moved: Ganesh Venkatesan38.3 Seconded: Emily Qi38.4 Discussion: Why not do the motion tomorrow?38.5 What is the plan for the other changes? – Ganesh to present tomorrow.38.6 EQ: speaks for the motion as the text is a big improvement on the current draft.38.7 GV: refers to Kevin Stanton’s presentation on Thursday and an advantage in

synchronizing with what is to be presented there.38.8 Result - 6/2/3 (For/Against/Abstain) Motion passes

39.0 Discussion on a rejection reason for CID 302. Chair to see if Jon Rosdahl can be present when the motion is moved.

40.0 Discussion moved on to CID 1274. Various technical reasons for rejection were discussed.

41.0 Recess at 21:30.

Wednesday November 12, 2008 AM1 Session, 08:00-10:00


42.1 Chair reviewed the agenda, see 08/1200r3

43.0 Presentation by Darwin Engwer, (DE, Nortel Networks), 08-1294-00 Enhancing BSS Transition Management

43.1 DE: Presenting on behalf of Kenan Xu, Nortel43.2 DE then presented 08-1295-01 Enhancing BSS Transition Management43.3 08-1295-01 shows the potential changes to the text



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

43.5 EQ: The text says it’s not mandatory.43.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?43.7 Ali Raissinia (AR): Clause 10 language that a station shall transition must move to clause

11 and be turned into a ‘may’.43.8 Kapil Sood (KS, Intel): How does the proposal add anything to the existing text, i.e.

where tspec fails?43.9 DE: Makes it a single atomic operation so it can’t be lost, and provides a candidate list

showing where to go.43.10 Kapil: but the STA can ask for a neighhood report within 10 ms43.11 DE: But the enhanced BSS transition will be faster, tighter and more efficient.43.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.

43.13 DE: Work with large numbers of handsets indicates it is not that rare.43.14 EQ: This is an enhancement that optimizes BSS transitions.43.15 KS: Would like to see more deterministic approach, i.e. in a heavily loaded system the

information is not advice but is mandatory.43.16 DE: That is good feedback.43.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.43.18 DE: Good feedback.

44.0 Straw polls:44.1 Do you agree that there is a need to streamline the BSS transition process as

described in this presentation? 44.2 Yes/No/Abstain: 2/0/14

44.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?

44.4 Yes/No/Abstain: 5/0/11

45.0 Motion 45.1 Move to adopt the comment resolutions for the Diagnostics category comment

indicated below, and include the indicated changes into the TGv draft45.2 CIDS 163,22745.3 Moved: Allan Thomson45.4 Seconded: Peter Ecclesine45.5 Result: 7/0/7 (For/Against/Abstain) Motion passes.

46.0 Presentation by Qi Wang, Broadcom, 08-1327-02, Proposed Solutions to LB133 CIDS 1239 and 1257

46.1 Qi covered differences between r1 and r2.46.2 No questions or comments.

47.0 CH: where are we with 1262?47.1 AT: we need to continue the discussion

48.0 CH: lets move on to discuss 1378

49.0 Presentation by Darwin Enger, Nortel Networks, 08-1378-00 Improving Multicast Reliability



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

49.2 DE: yes it is very dynamic49.3 AT: has this proposal changed since last presented?49.4 DE: No, this is revisiting with highlighting different benefits.49.5 AT: then the original concerns have not been met49.6 DE: thought they had been.49.7 EQ: people mostly concerned to hear the benefits49.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.

49.9 PE: Benefits relate mostly to running at 10 Mbps and less. Please solve the problems at low rates for television white space.

49.10 DE: fundamental problem is contention for the medium not the data rate.49.11 HP: Does the AP need to wait for stations to wake in order to service stations?49.12 DE: Yes.49.13 EQ: Teardown is buffered. There is no specific text on when ap ceases service.49.14 DE: gives examples of scenarios involving printers49.15 KS: Speaks in support of proposal.49.16 AT: responding to example, could be an application layer problem?49.17 DE: yes49.18 CH: do you want to make a motion?49.19 DE: yes

50.0 Motion: 50.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”

50.2 Moved Darwin Engwer50.3 Seconded Emily Qi50.4 No discussion50.5 Result 6/2/8 (For/Against/Abstain) Motion passes

51.0 CH: What is the status of submissions to resolve the event comments?51.1 AT: document is just posted (~9.30)51.2 JK: There are two solutions to the same CIDs in r1 and r2 that need to be worked out.51.3 CH: is that a request for a straw poll?51.4 JK: yes but just before the vote51.5 AT: It would be better to walk through r2 first51.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?51.7 AT: yes51.8 HP: The management console could do some of this?51.9 AT: it’s a scaling question, i.e. distributed vs centralized51.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.

51.11 AT: Hhow do you solve the problem51.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.51.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.



51.14 AT: That is the benefit of putting UTC in the beacon, but it sounds like a good proposal51.15 JK: valid proposal. The timestamping has only one time base which is good. It works for

all cases seen at the moment.51.16 DE: 11p has an mlme interface to make adjustments to the tsf which need to be

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

51.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.0 Meeting recessed at 10:00

Wednesday November 12, 2008 PM1 Session, 13:30-15:30



54.0 Presentation by Chen Zhang, (CZ, China Mobile), 08-1321-00 Table of inferential APs using same channel

54.1 AT: Have you considered the neighbour mib in 11k?54.2 CZ: We have considered but not enough information.54.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.54.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.

54.5 CZ: Table updated periodically and queried periodically, not a log.54.6 QW: We already have neighbor table, how is this difference? Who decides that

interference is happening?54.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.

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

54.9 CZ: Location information may not be correct. RF information will always be right.54.10 JK: you can rely on beacon report.54.11 AT: question on use case – is there an assumption of a higher layer management function

that will effect change to reduce interference – correct?54.12 CZ: We can use the information to find which operator an AP belongs to so we can

alleviate interference manually or automatically.54.13 AT: Sounds like a very manual operation which may not solve the problem.54.14 CZ: Without this information we must send someone to measure the problem on-site.54.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.



54.16 RD: Please define your concept of interference, is it 100 mw access points or high powered p2p bridges?

54.17 CZ: see definition on slide 554.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.

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

54.20 CZ: OBSS management is necessary in applications.54.21 GS: some sort of DFS is preferred

55.0 Straw poll55.1.1 Do you think it meaningful to add such kind of measurement and reporting

parameters to keep the network more controllable?55.1.2 Yes 2, No 2, Abstain 19

56.0 Presentation by Chen Zhang, China Mobile, 08-1322-00 Times of refused associated requests by the restriction of user limits

56.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?

56.2 CZ: single value per BSS56.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.56.4 CZ: just association with not relation to security56.5 MH: I don’t see anything for refusal due to admitted traffic streams. Is that correct?56.6 CZ: Not related to QOS refusals.56.7 MH: there’s an assumption that when AP is full it refuses further associations regardless

of traffic load presented56.8 CZ: correct56.9 MH: that seems too simplistic. You need to consider admitted QOS traffic streams56.10 CZ: using number of associations is simple and effective56.11 CH: on slide 5 it shows it’s a simple average56.12 QW: Is there a time unit? Hour, day?56.13 CZ: We assume a period of less than one hour. 5 minutes is very good.56.14 QW: So you track a sliding window and use histograms etc. How do you use the

information?56.15 CZ: explains how in general56.16 RD: This is a simple method of load balancing is it not? 56.17 CZ: No it is not designed to prevent associations.56.18 QW: is this for traffic analysis or load balancing?56.19 CH: go to slide 5. Looks like the intent is to gather information only and process off-line56.20 RD: But slide 7 indicates that the number is used to limit associations.56.21 CH: No the counter is incremented when association is refused.56.22 MH: then load balancing must be on56.23 CZ: but there may be other reasons for refusal as well56.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.

56.25 GS: seems a reasonable submission deserving of support. Agree with Joe’s comments on terminology.

56.26 RD: Speaking against it due to the confusion caused by terminology.

57.0 Straw poll:



57.1 Do you think it meaningful to put the Dot11NumRefusedAssociatedForUserLimitcounter into the MIB to facilitate some service and network quality?

57.2 5/2/15 (yes/no/abstain)

58.0 Presentation by MM Montemurro, (MM, Research in Motion), Prioritized Action Frames58.1 GS: Likes the idea. Is it more or less priority than a normal mgmt frame, e.g. ACVO?58.2 MM: It is flexible.58.3 HP: Management frames currently go at ACVO. This creates a frame type that can go at

a different priority.58.4 GS: Can we make it mandatory?58.5 PE: Make it an alternative sub-type number if possible.58.6 MM: We are flexible.58.7 AT: This new frame is only for events and diagnostics?58.8 MM: yes58.9 AT: So the intention is that these frames are treated as lower priority than other mgmt

frames?58.10 MM: it allows this.58.11 AT: The reason for introducing was to protect the sta from requests.58.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.58.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.

58.14 MM: action field values should not need to change.58.15 EQ: WNM uses a particular subtype58.16 MM: you want some additional text? Refer to 7.19a, the frame body does not change.58.17 MH: I haven’t seen how this affects EDCA values therefore these frames are still sent at

ACVO?58.18 MM: I didn’t find anywhere this can be added.58.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.58.20 MM: okay, assistance welcomed.58.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.

58.22 MM: there are tradeoffs. Events and diagnostics should be fixed first since they are known problems.

58.23 Andrew Myles (Cisco): we should take time to solve the larger problem.58.24 HP: wrt 802.11w the replay counter text needs to be sorted out.58.25 AM: this is still the wrong group to solve the general problem involving 11e, 11w, 11v

and 11k etc58.26 RD: in favour of the submission. Events and diagnostics need to be taken care of within

11v now.58.27 AR: not sure we need a sub-type.58.28 MM: In July a subtype was voted as the only viable option58.29 HP: a subtype is required to add the QOS header to allow 11w to work58.30 AR: table 7.4 needs clarification 58.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?58.32 HP – no58.33 NCW : Concerned there may be hardware implications and that there may be changes to

11w



58.34 JK: supports general idea of prioritized management frames. We should make this change in 11v and other changes go to TGmb.

58.35 MH: agrees with Joe K. Action frames have special treatment under power save that needs to be considered.

58.36 HP: What is amendment ordering?58.37 CH: v follows w.58.38 PE: mb follows existing pars. Everything published before mb gets rolled into mb.58.39 DH: Question to CH about timeline.58.40 CH: 11v due July 2010.58.41 DH: timing vs TGmb is tight

59.0 Motion:59.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

59.2 Discussion:59.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.59.4 MM: speaking for, changes required are minor.59.5 Moved: MM Montemurro59.6 Seconded: Henry Ptasinski59.7 Result: 11/6/4 (For/Against/Abstain) Motion fails

60.0 Motion60.1 Move to adopt the comment resolutions for the general category comments

indicated below, and include the indicated text changes into the TGv draft:60.1.1 CIDS 1239, 1257 – counter “incorporate text changes in 08-1327-02”

60.2 Moved: Qi Wang60.3 Seconded: Ganesh Venkatesan60.4 Result: 16/0/4 (For/Against/Abstain) Motion passes

61.0 Motion:61.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

61.2 Moved: Allan Thomson61.3 Seconded: Qi Wang

61.3.1 Discussion:61.3.2 Joe K: the group should review the document61.3.3 CH: the document was on the server for 4 hours and the motion is in order. 61.3.4 Joe K: I have comments. The presentation is well done with good provisions.

Why is the timestamp in the beacon and probe responses?61.3.5 HP: stations may be able to use it for setting time and other purposes and

may need it immediately on BSS transition61.3.6 Joe K: Why is accuracy in beacons etc and not in reports in case of varying

accuracy across different APs?61.3.7 HP: Across an ESS we assume the time base will be consistent with

reasonable accuracy.61.3.8 Roger: Important to differentiate declarations of time with different

accuracy, e.g. GPS vs other clocks.61.3.9 DH: Would prefer use of ESS time rather than UTC.61.3.10 HP: UTC is convenient and well recognized and global to the ESS.61.3.11 AT: UTC convenient choice.



61.4 Result: 15/0/5 (For/Against/Abstain) Motion passes.

62.0 Motion:62.1 Move to adopt text changes in 00-1371-00 into the TGv draft62.2 Moved: Ganesh Venkatesa62.3 Seconded: Qi Wang62.4 Discussion: 62.5 Ali: Is this mandatory or optional?62.6 GV: optional62.7 Ali: are you serious about 10 ns accuracy62.8 GV: yes62.9 Ali: you mean accuracy or resolution62.10 GV: it’s the unit, we can talk offline62.11 Ali: ok62.12 Result: 12/1/6 (For/Against/Abstain) Motion passes

63.0 Recess at 15:30

Thurssday November 13, 2008 PM2 Session, 16:00-18:00



65.0 Discussion on CID-251 (see 08-1200-07)65.1 RD: If motion simply declined then would agree, but does not agree on first bullet item in

1200-07 for motion on CID251.65.2 CH: bullet points reflect feedback from all group to commenters.65.3 Mark: Change sentence to read: “Concerns that were raised include65.4 Roger: Would like to be diplomatic65.5 HP: These points are in the minutes, prefer to refer to minutes65.6 Roger: agree65.7 AT: agree65.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.

65.9 General agreement on referring to the decline reasons being in the minutes.65.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.65.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.65.12 AT: Believes technical reasons are captured in the minutes.65.13 BM: this method of operation will only be acceptable until we achieve letter ballot65.14 MM: As a former secretary is is okay to refer to the minutes.65.15 Mark: The case is that we didn’t like the proposed resolution.65.16 AT: Didn’t we say referring to minutes was okay?65.17 EQ: This proposal only addresses part of the problem.65.18 MM: The commenters need sufficient feedback on how to address the feedback65.19 JK: Should also say commenter is acknowledged and encouraged to present at the next

meeting.



66.0 Motion66.1 Move to adopt comment resolutions for CID251 as declined66.2 Moved: Mark Hamilton 66.3 Seconded: Joe Kwak66.4 Results: 3-1-12 (For/Against/Abstain) motion passes

67.0 Motion 67.1 Move to adopt the comment resolutions for CID 1274 as declined67.2 No discussion67.3 Moved: Allan Thomson67.4 Seconded: Emily Qi67.5 Result: 7-1-8 (For/Against/Abstain) motion passes

68.0 Motion68.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.68.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”

68.3 Moved: Qi Wang68.4 Seconded: Emily Qi68.5 Result: 8-2-6 (For/Against/Abstain) Motion passes

69.0 16-25 Presentation by Joe Kwak, InterDigital Communications, 08-1396-00 LB133: Normative Text Update for Annex Q

69.1 RD: Transmitter power p87 line 27-28. Why can’t I find this on Joe’s document? (found on a different line)

69.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.0 Motion70.1 Move to adopt the text changes in 11-08-1396-00-000v-normative-text-annexq-

update.pdfinto the TGv draft.70.2 No discussion70.3 Moved: Joe Kwak70.4 Seconded: Allan Thomson70.5 Result: 10-0-3 (For/Against/Abstain) motion passes

71.0 Adhoc dates discussion:71.1 JK: When will LB start and end?71.2 CH: 17-19 Nov and would go out for 30 days71.3 PE: 40? For recirc?



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

71.5 Peter E: not expecting to recirc out of Jan?71.6 CH: plan is to recirc out of March71.7 AT: Who will be at the adhoc? Concerned about having it.71.8 CH: If we scheduling an adhoc it requires planning.71.9 QW: Prefer to work offline.71.10 AT: Travel is expensive and constrained currently. The adhoc may not be justified if it

requires travel71.11 CH: Are you volunteering to host?71.12 AT No, just questioning the value.71.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.0 Straw Poll72.1 TGv should authorize an adhoc in Feb 200972.2 Discussion:72.3 Roger: if LB passes would attend adhoc but probably not otherwise72.4 Dorothy: would like to organize the adhoc and confirm or cancel in January

72.4.1 Yes: 572.4.2 No: 072.4.3 Abstain: 13

73.0 Motion73.1 Move to authorize a TGv Ad-hoc73.2 Feb 16-18, 2009 (Mon-Weds), in San Jose area, host tbd73.3 Mover: Joe Kwak73.4 Seconder: Fujio Watanabe73.5 Result: 3-1-12 (For/Against/Abstain) Motion passes

74.0 Motion74.1 Motion to authorize TGv teleconferences Jan 6, 13, Feb 3, 10, 17, Amr 3 200974.2 Mover: Emily Qi74.3 Seconder: Fujio Watanabe74.4 Discussion

74.4.1 JK: One date is when adhoc is on74.4.2 CH: one or other conference will be cancelled

74.5 Result: 7-0-7(For/Against/Abstain) Motion passes

75.0 Discussion on waiting 22 minutes until four hour rule for next motion has been met75.1 P: If not a draft you can vote now75.2 BM: you are changing a draft and must wait four hours75.3 CH: not worth the risk, wait another 22 minutes, take a 15 minute recess

76.0 17:23 Chair: Meeting called back to order

77.0 Motion77.1 Move77.2 To adopt TGv Draft 3.04 as the TGv draft, 77.3 To instruct the editor to renumber TGv Draft 3.04 as Draft 4.0 and 77.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?”77.5 Mover: Emily Qi77.6 Seconder: Allan Thomson77.7 Discussion:



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

77.9 Question from floor: Is it 30 or 40 days for LB77.10 CH: 30 is correct77.11 Result: 11-0-5 (For/Against/Abstain) Motion passes

78.0 No further business. Meeting adjourned 17:28.



References:


doc.: IEEE 802.11-08/1353r0 · Web viewYes -10, No – 6, Abstain – 6 CH: Reviewed...

Documents

Transcript of doc.: IEEE 802.11-08/1353r0 · Web viewYes -10, No – 6, Abstain – 6 CH: Reviewed...