August 2007 doc.: IEEE 802.11-07/2282r3
IEEE P802.11
Wireless LANs
Date: 2007-08-022
Author(s):
Name / Company / Address / Phone / email
Eldad Perahia / Intel Corporation / 2111 NE 25th Ave
Hillsboro, OR 97124 / 503-712-8081 /
1 Conference Call Times
Date / Start Time / End TimeJuly 25 / 11 AM Eastern Time / 1 PM Eastern Time
August 1 / 11 AM Eastern Time / 1 PM Eastern Time
August 22 / 11 AM Eastern Time / 1 PM Eastern Time
2 Attendance
Participant / July 25 / August 1 / August 22David Bagby (Sanyo and/or Calypso Ventures) / x / x
Bjorn Bjerke (Qualcomm) / x / x
Doug Chan (Cisco) / x / x / x
Vinko Erceg (Broadcom) / x / x
Matt Fischer (Broadcom) / x / x
Pratibha Gupta (Atheros Communications) / x / x / x
Padam Kafle (Nokia) / x
Bruce Kraemer (Marvell) / x / x
Michael Livshitz
(Metalink) / x
Peter Loc (Marvell Semiconductor Inc.) / x
Eldad Perahia (Intel) / x / x / x
Jim Petranovich (Conexant Systems, Inc.) / x / x / x
Dick Roy (????) / x
Atul Salhotra (Marvell Semiconductor Inc.) / x
Adrian Stephens (Intel) / x / x
Solomon Trainin (Intel) / x / x / x
Allert van Zelst (Qualcomm) / x / x
3 Minutes from July 25 2007 Conference Call
3.1 Agenda
· Check to see if anyone is not familiar with the IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.pdf
· Submission by Matt Fischer
– 11-07-2020-07-000n-lb97-cid-2582-bss-width-switching.doc
– 11-07-2280-00-000n-lb97-cid-79-coex-more-20-40.doc
3.2 Patent Policy
Noone was unfamiliar with the IEEE patent policy.
3.3 Discussion on 07/2020r7
• Discussion regarding Supported Channel Width Set field and AP, add
– Note – the Supported Channel Width Set field transmitted by an AP is constant for the lifetime of its BSS as it is a parameter of the MLME-start.request primitive.
– Dick Roy raised the issue of decoupling scanning requirement from Supported Channel Width Set field. Matt raised the point that this was discussed last week and no one indicated interest. In interest of time, Eldad requested Dick Roy create a submission on the issue.
• Move up the line & modify “The Extended Channel Switch Announcement element can be used to indicate…”, issue is that this and Secondary Channel Offset field convery the same information and we need to tighten up language.
• CID2582
– Modify to “An AP switches the BSS channel width between 20/40 MHz and 20 MHz by changing the value of the Secondary Channel Offset field of the HT Information element in the Beacon and/or by changing the value of the Secondary Channel Offset field of the Secondary Channel Offset element.”
– Need to add statement regarding ECSA
– Undo deletion of “making a channel width change or while”
• Pratibha Gupta asked if we polled acceptance of this document
– Eldad: no, there are too many changes. We will review again in Sept pre-meeting
3.4 Discussion on 07/2280r0
• Update year on header
• CID 170, modify resolution text to call out legacy and other systems in 2.4 GHz
• Discussion regarding TBDs in MIB value, concern was raised the we are resolving CIDs without actual values
– Eldad stated that at least one CID which specifically addresses scanning values will returned by Editor as EMR or ER
– Discussion will take place in September pre-meeting on TBDs
– The EMR CID will not be resolved until we have agreed upon values for TBDs.
• No objection to accepting 07/2280r0, including changes to header and CID 170 (which will be in r1) to resolve CIDs listed in said document and bringing to motion in TGn in September.
4 Minutes from August 1 2007 Conference Call
4.1 Agenda
· Check to see if anyone is not familiar with the IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.pdf
· Submission by Solomon Trainin
– 11-07-2054-01-000n-tgn-lb97-coex-dfs-ch-sel.doc
– 11-07-2055-00-000n-tgn-lb97-coex-ch-switching.doc
• Submission by Vinko Erceg
– 11-07-0611-03-000n-lb97-coex-20-40-coex-comments-resolution.doc
• Submission by Bjorn Bjerke
– 11-07-2098-02-000n-lb97-coex-deferred-dfs-channel-selection-comments.doc
4.2 Patent Policy
Noone was unfamiliar with the IEEE patent policy.
4.3 Discussion on 07/0611r3
· Continue with CID 2465
· CID 2466
o “20/40 MHz”, “20/40 capable”, “20 MHz capable” occur in more clauses, subclauses than 9.20 and 11.15
o Spec will be messy if we have to have the definitions in every clause
o Move FC HT STA, non-FC STA definitions to new clause 3a
o 07/614r10 move definitions to 9.20, remove these as well
· Definitions for “20 MHz BSS” & “20/40 MHz BSS”
o Use specific names of fields
o Also refer to element it comes from
· PCO definitions were update from r2 to r3
4.4 Discussion on 07/2055r0
· Fix header
· CIDs with resolution to transfer to 07/614 need to be changed, since 07/614 is already motioned
· CID 419, 2123
o Eldad to check with Adrian if the transfer to editorial is acceptable
· CID 556, 1745, 2484, 2492, 2504, 2506, 2507, 3049, 3050, 2508, 3051, 3078
o Remove from document, already in 07/2020r8
· CID 2872, 2486, 2505, 2591
o Remove from document, already in 07/614r10
· CID 2487
o Eldad to check with Matt regarding transfer 07/2020
· CID 3331, 3332, 263, 264
o Can not transfer 07/614
o See if is resolved by 07/614
· CID 3333
o Change resolution to Refer to 07/614r10, CID 3272
4.5 Discussion on 07/2054r0
o CID
o CID 2893, 2894
o Currently E-CSA is required and requires DFS as TGy4.0, clause 11.9.7, line 34-35
o Solomon would like to extract E-CSA from DFS and modify that sentence from TGy4.0
o These changes will be made to TGn draft and not TGy
o Solomon will present in Aug 22. Need to give this priority on the call, since Solomon will not be in Hawaii.
4.6 Discussion on 07/2098r2
· Slight change from r1
· CID 651
o Bruce: why reject rather than counter?
o Bjorn: text was already in 11.9.8.3 in D2.0
· CID 589
o Bruce to send further reminder to commenter
· CID 1870, 3083, 2581
o Eldad to check with Matt regarding transfer 07/2020
· No objection to accepting 07/2098r3, which will have CID 1870, 3083, 2581 deleted, and bring to motion in TGn in September
· Bruce made noted that CID589 may need to be reopened if we get a response.
5 Minutes from August 22 2007 Conference Call
5.1 Agenda
· Check to see if anyone is not familiar with the IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.pdf
· Submission by Solomon Trainin
– 11-07-2326-00-000n-tgn-lb97-coex-cid-2893.doc
– 11-07-2055-03-000n-tgn-lb97-coex-ch-switching.doc
· Submission by Matt Fischer
– 11-07-2020-10-000n-lb97-cid-2582-bss-width-switching.doc
5.2 Patent Policy
Noone was unfamiliar with the IEEE patent policy.
5.3 Discussion on 07/2055r3
• No technical changes between r1 and r3, changes in submission related to removal of CIDs addressed by other submissions.
• No objection to accepting 07/2055r3 and to resolve CIDs listed in said document and bringing to motion in TGn in September.
5.4 Discussion on 07/02326r0
· Completely separate E-CSA from Spectrum Management and not require Spectrum Management of HT STAs
· Submission still includes mandatory support of E-CSA by HT STAs
· Bjorn: is 11.9a mean something like 11.10 or 11.11?
o Yes: 11.9a means same layer as other subclauses in clause 11
· Bjorn: dot11ExtendedChannelSwitchImplemented used as a dynamic parameter in the STA depending on the capability of BSS?
o Solomon: Yes
o Matt: slight problem with wording. Need to add “at association”. In BSS, should only pay attention to AP and IBSS pay attention to other STAs
· Matt: does Adrian have issue with the “AP may reject association…”?
· Pratibha: removed coupling with dot11RegulatoryClassesImplemented?
o No, dot11ExtendedChannelSwitchImplemented is coupled to dot11RegulatoryClassesRequired which implies dot11RegulatoryClassesImplemented
· Matt: replacing 11.9.7.1?
o No, referencing it.
o Paragraph in 11.9a.2.1 uses 11.9.7.1 as template
· Matt: In “An AP shall inform associated STAs that the AP is moving to a new channel and maintain the association by advertising the switch using Extended Channel Switch Announcement elements in Beacon frames, Probe Response frames, and Extended Channel Switch Announcement frames until the intended channel switch time.” is it “shall inform” and “shall maintain” or “should maintain”?
o Same intent as 11.9.7.1
o Matt: leave the sentence unchanged for now, since the same intent as 11.9.7.1
· Matt: “An AP that advertises switching shall transmit Extended Channel Switch Announcement element and/or Channel Switch Announcement elements in Beacon frames and Probe Response frames.” restricts the use of action frame
o Matt to rewrite paragraph
· Pratibha: Case where dot11ExtendedChannelSwitchImplemented in AP is true but not in any STAs, AP would still need to send E-CSA and this is added overhead
o this is corner case
· Adrian: need to fix editorial instructions in 7.3.2.27
· Discussion on where the changes to be made (issue is that the text being changed is in TGy), TGn or TGy. After lengthy discussion:
o Make changes in TGn
o Need to track TGy
o If changes are later consolidated in TGy, then will be removed from TGn.
· Matt: in Tables should dot11RegulatoryClassesRequired be left?
o When dot11ExtendedChannelSwitchImplemented is true, dot11RegulatoryClassesRequired is required so it does not need to be in the table.
· Matt: in last two tables, why add “and dot11ExtendedChannelSwitchImplemented is false”
o Solomon: Regulatory classes is enough
5.5 Discussion on 07/2020r10
· New changes from r7 reviewed.
· Adrian: concerned with changes due to CID 2583 and in 07/02326r0 are similar
o Solomon: do not need the green part
o Adrian: Solomon’s text is for channel switching, this is for channel width switching
· Bjorn: move 11.9.8.4 out of 11.9, since it is not related to DFS
· Matt: we really need to consolidate all the channel switching text
o Adrian: wait till after LB
· In first paragraph of changes for CID 2583:
o Delete green
o Look to modify clause header to account for IBSS
· Adrian: Does resolution to CID 2134 conflict with 9.6?
o Matt: can add reference to 9.6
Submission page 6 Eldad Perahia, Intel