<p> November 2007 doc.: IEEE 802.11-07/2773r0</p><p>IEEE P802.11 Wireless LANs</p><p>TGP Teleconference</p><p>Date: 2007-November 8</p><p>Author(s): Name Affiliation Address Phone email California PATH, University of California, Berkeley Institute of Transportation Susan R Caltrans Studies 1(510)665-3664 [email protected] Dickey .edu Richmond Field Station, Bldg. 452 1357 S. 46th Street Richmond, CA 94804-4648</p><p>Abstract This document includes the minutes of the IEEE 802.11 TGp WAVE Task Group teleconference on Thursday, November 8, 2007, chaired byTask Group Chair Lee Armstrong of Armstrong Consulting (affiliation USDOT), editor Wayne Fisher of ARINC (affiliation USDOT) chaired the telecon. Minutes were taken by Susan Dickey of. California PATH (affiliation Caltrans).</p><p>Submission page 1 Susan Dickey, California PATH November 2007 doc.: IEEE 802.11-07/2773r0</p><p>Lee Armstrong (affiliation USDOT) started the teleconference at 3 pm Eastern Time, with Wayne Fisher (affiliation USDOT), Francois Simon, (affiliation USDOT), Susan Dickey (affiliation Caltrans) on the line. Carl Kain (affiliation: USDOT), Richard Roy (affiliation Connexis).</p><p>Simon has been going through the comments, and has a questions of whether we need an ECIE bit for WAVE mode as well as for an On-Demand Beacon Frame.</p><p>Roy’s reply was that we do not need this, according to the following reasoning: How does a STA know if it’s in WAVE mode? A STA is in WAVE mode when the MIB attribute dot11WAVEServicesEnabled is TRUE, regardless of what frames it has received. How does a STA know that it has received an On-Demand Beacon Frame? Because the appropriate bit has been set in the Extended Capability Information Element. What will a STA do when it receives a WAVE Services Information Element? If it is a WAVE STA, it will process the WSIE, otherwise it will ignore the WSIE. What will a STA do when it receives an On-Demand Beacon Frame with no WSIE? If it is a WAVE STA that wants to synchronize, it will use the timing information contained. Will legacy STAs be confused by receiving an On-Demand Beacon Frame? A legacy STA is unlikely to be listening when an on-demand beacon arrives, since it is not likely to be at a time it is schedule to wake up and listen for beacons. Even if the legacy STA does not recognize the ECIE, the on-demand beacon will not contain what looks to a standard device like a BSS announcement or update from an AP with which it is associated, and thus will likely be ignored. And since initial deploymens of WAVE will be in licensed bands, there won’t be any legacy device in the band anyway.</p><p>Simon raised the JOIN primitive issue. In the original “Wave Announcement” – Action Frame - solution we did have a specific WAVE join primitives – MLME-WAJOIN.xxx. At the Montreal meeting, when the decision was made to use the 802.11 Std. beacon frame format in WAVE mode (see Doc.: IEEE 802.11 11-07-0781-02-000P), Justin McNew proposed to “Remove MLME-WAJOIN.xxx and modify MLME.JOIN.xxx (if required)”. This resulted in the current logic in P802.11p/D3.0</p><p>/* 10.3.3.1.2 - MLME-JOIN.request*/ if dot11WAVEServicesEnabled = false then /* 802.11 Std-2007 */ The primitive parameters are as follow: MLME-JOIN.request ( SelectedBSS, JoinFailureTimeout, ProbeDelay, OperationalRateSet, VendorSpecificInfo ) else</p><p>The primitive parameters are as follow: /* P802.11p/D3.0 */ MLME-JOIN.request ( BSSID, SSID, OperationalRateSet, Timestamp, LocalTime, EDCA parameter set ) endif Submission page 2 Susan Dickey, California PATH November 2007 doc.: IEEE 802.11-07/2773r0</p><p>/*10.3.3.2.2 – MLME-JOIN.confirm */ if dot11WAVEServicesEnabled = false then /* 802.11 Std-2007*/ The primitive parameters are as follow: MLME-JOIN.confirm ( ResultCode, VendorSpecificInfo ) else</p><p>The primitive parameter is as follow: /* P802.11p/D3.0 */ MLME-JOIN.confirm ( ResultCode ) endif</p><p>The issue with this is that all 802.11 devices have to test the dot11WAVEServiceEnabled MIB attributes to find out which path to take for MLME-JOIN.request and MLME-JOIN.confirm primitives. We have around about 7 comments addressing this issue. Simon said the only solution I can think of is to revert to WAVE specific primitives. BTW that is the Suggested Remedy from the CRs.</p><p>Roy said we don’t need JOIN, we need a SET-PARAM primitive. In the standard join procedure, the first thing we do is set the radio parameters. After some discussion, Simon said he would try put Roy’s suggestions on paper tonight.</p><p>Simon mentioned outstanding issues on section 5, we did not discuss those since Rai and Kenney, authors of IEEE 11-07/2530 are not on the line. Simon asked Dickey about Clause 7 frame usage and Clause 11. A proposed frame usage comment resolution document is on the server as IEEE 11-07/2748r0, please review. For clause 11, she is working on a comment resolution document with Vinuth Rai and John Kenney, but has not finished with the resolutions for all Clause 11 comments. It was difficult to turn the suggestions in IEEE11-07/2668r0 into precise editing instructions without also including comment resolutions for other comments on 11.14.1, 11.14.2 and 11.14.3.</p><p>Simon raised a question about the comments on 7.1.3.3.3. Roy said it should be good if we just say it is a locally administered IEEE MAC address. End of story, detail about generation not required.</p><p>Simon asked about last week’s discussion on the beacon interval, as far as is known everyone agrees that it should be changed to unspecified rather than 0xFFFF.</p><p>Simon has uploaded 2727r0 which deals with the comments about inconsistent and incomplete definitions of on-demand beacon fame and WAVE advertisement frame.</p><p>Kain: has gone through most of the clause 17 comments, and believes he has reasonable and non- controversial ways to fix them. However some of them went back to the presentations that Mary Ann made back in Orlando. There are basically two issues: we want tighter numbers and we should hold that stance, but the actual numbers in our table look wrong. The difference between the adjacent channel rejection and minimum sensitity should be a constant. Ours are tighter, but we don’t maintain that constant. IEEE 11-07/0449r0, related to comment number 774 of LB92, has corrected numbers that we </p><p>Submission page 3 Susan Dickey, California PATH November 2007 doc.: IEEE 802.11-07/2773r0 may want to adopt on slide number 8. Our numbers originally came from discussions with Atheros and Intersil, as Kain recalls. Kain asked that we look this over before next week</p><p>Armstrong commented that we are as ready as we can be for next week, and adjourned the meeting at 4:30 pm Eastern time.</p><p>Submission page 4 Susan Dickey, California PATH</p>