January 2008 doc: 11-08-0193-00-000p
IEEE P802.11
Wireless LANs
Date: 2008-01-16
Author(s):
Name / Affiliation / Address / Phone / email
Rick Noens / Motorola / 1299 E. Algonquin Rd. Schaumburg, IL / +1.847.576.1163 /
TGp January 14, 2008 AM 2 (17 Attendees)
Meeting Notes
· The chair, Lee Armstrong, called the meeting to order
· Document 11-08/0093r0 was used to start the meeting in which membership rules, affiliation rules, anti-trust laws, patent bylaws, attendance rules, voting rules and meeting rules were reviewed by the chair. All participants were asked if the understood these rules and bylaws and the response was affirmative.
· The chair made a call for any knowledge of essential patent claims or letters of assurance. There was none brought forward.
· The chair reviewed the new voter ID scheme and the fact that the number on the members badge is no longer their voting ID. The ID is now the IEEE SA PIN which can be viewed on the IEEE Web Account website.
· The chair reviewed the goals of this meeting which were:
o Review outcome of previous meetings regarding LB 110
o Continue LB 110 comment resolution
o Approval to go back to LB
· The chair reviewed the timing that is needed during these meetings to be able to vote on a motion to go to LB.
· The chair asked that if any members have issues that need discussion that they bring them up as early as possible during this meeting so that time can be made for discussions.
· It was discussed and agreed that going to LB as soon as possible should be a goal but that we should not take short cuts in doing so.
· Vinuth Rai, John Kenney and Susan Dickey have generated document 07/2668r1 for discussion but it is not yet on the server. It will be later today so it was added to the agenda for the Tuesday PM 1 session since it will be on the server by more that 4 hours prior to that time.
· The chair reviewed the agenda and it was unanimously approved.
· The meeting notes from the November meeting in Atlanta were approved unanimously.
· The chair requested that if you have sent him an urgent email over the past 4 weeks, that you re-send it due to the fact that he had been experiencing computer problems.
Liaison Reports
IEEE P1609 (Tom Kurihara)
· There are currently no meetings scheduled for 2008.
· Nothing has changed from the report given in the November meeting.
· The most immediate issue is that the 1609 documents are trial use and the trial periods are ending over the next year. The first is 1609.2 which expire in May or June of 08. According to our understanding the trial use standards will become full standards unless comments are made which need to be addressed. Tom wasn’t aware of a process that would allow for an extention of the trial use period to collect more feedback other than responding to comments.
· John Kenney suggested that, if time permits, an adhoc brainstorming session occur among interested parties to determine where we go from here.
· Francois Simon noted that the 1609.0 daft has been out for comments for more than 3 months and no feedback has yet to be received.
ISO (Dick Roy)
· WG 16 has document 24102 out for comment. Dick can provide it to those who would like a copy.
· WG 16 will have document 21215, which has 30 MHz channelization, for comment shortly.
· The next meeting of WG 16 will be in Korea the week of March 10th.
· WG 17 is a new work group which is still developing this scope. The standard is expected to apply to Personal Area Networks in the car. The first meeting of the WG will be in Korea in conjunction with WG 16 and it will be on March 12th. The intent is to standardize interfaces for devices carried into the car.
Midamble Presentation
Dr. Hanbyeog Cho of ETRI presented on a method to improve the throughput of large packets in the DSRC environment. The document is not yet on the server but will be added. This presentation should be considered as informative. From a high level the concept presented was to use additional “training” in larger packets to improve error correction. The subsequent discussion indicated that some TG members believed that smaller packets were important due to a likely hidden STA rich environment.
Comment Resolution Notes
· The 4 hour rule applies to making technical changes to the draft document.
· The chair clarified that the 4 hour rule was relating to 4 hours of meeting time with the red box in the meeting schedule for 802.11. In other words, a document subject to the 4 hour rule must be placed on the server 4 hours prior to discussing it with the elapsed time being calculated within the red box in the meeting schedule for a particular meeting.
· Francois Simon has put together a document which has several motions for resolving CIDs as well as a proposed new draft of our document. The TG discussed the alternatives of voting on accepting the new draft versus going through the motions. The reason to want to approve the new draft proposal is to expedite progress as going through the motions would be very time consuming.
· The jeopardy of approving the proposed new document and then looking at approving the specific CID responses was discussed. Since we are not working on a WG approved draft it was decided that approving the new draft was the best way to go and that any issues and/or concerns with specific CID actions could be addressed later.
· There was a discussion on whether Doug Kavner’s proposal in Atlanta should be applied to a new draft and if it related to 11p or 1609 or both. I was decided that Lee Armstrong and John Kenney would take this discussion off line and come back to the TG with a recommendation.
· The chair volunteered to distribute the latest working draft of 11p, not an official document, to help in facilitating discussions this week.
Meeting was recessed until PM 1 tomorrow.
TGp January 15, 2008 PM 1 (20 Attendees)
Meeting Minutes (continued)
· John Kenney presented document 07 2668r1 which was developed to address several CIDs
o Sync Discussion
§ John stated that we had discussed Sync in November and he believed that we had come to an agreement. Dick Roy disagreed and said that the sync concept was wrong.
§ A discussion on the need for sync followed. Dick Roy said we don’t need this do to higher layers managing it.
§ John stated that Clause 11.1 shouldn’t apply in WAVE Mode and that we should state that prior to 11.1 and point to 11.14 (soon to be 11.18 per other group’s additions.) John, Vinuth, and Susan are proposing this approach rather than the approach taken previously which was to embed text in numerous places in 11.1 describing how WAVE Mode is different. This latter approach lead to many comments on LB 110 and is confusing to the reader.
§ It was noted that the reference in D3.0 Clause 11.1.1.3 to 11.2 is wrong and should be changed to 11.1.2.
§ Dick stated several times that we should not have WBSS in the 11p document as it doesn’t exist.
§ John pointed out that since we state that Sync is optional in WAVE Mode we are obligated to describe how to use it rather that just say it is out of scope for 11p.
§ Vinuth suggested that we could say that Sync is done at higher layers and will utilize the TSF commands in Clause 10.
o 11.14 WAVE Mode Management Discussion
§ John suggested that we skip the first part of this clause as it will be a time consuming discussion and we’ll get back to it.
§ During the 11.14.1 (Initializing a WAVE BSS) discussion it was pointed out that the On Demand Beacon is only for Sync but that you can announce (WIE) on it but you don’t need to.
§ Dick pointed out that 11 can only transmit on the channel it is on so we don’t need restrictions the last sentence in 11.14.1 imposes. He wanted the sentence removed.
§ We need to change the word “advertisement” in the 3rd paragraph of 11.14.1 to “announcement”. We also need to reword to remove the “shall” because we are making a primitive normative.
§ We also need to remove the “shall” from the 4th paragraph.
§ There was a discussion on how much we need to put in the document on initializing WAVE BSS. It was agreed that we should keep it to a minimum but agreement on what constitutes a minimum was not reached.
§ Dick Roy stated that 11p should be allowed to transmit data without an IBSS or BSS. It should send BSSID without being in IBSS or BSS.
§ The group agreed that we need a WAVE BSS and On Demand Beacon for timer reasons.
§ Moving to 11.14.2, the group agreed that we need to remove the shalls from this sub clause for the same reasons of making a primitive normative.
§ We need to change the wording to indicate that the logic control is above “if a STA’s upper layer chooses to join”. The key difference is in 11p joining decision is at a higher layer while in traditional 11 it’s done at the MAC layer.
§ Because of the issue of joining it was suggested and John said he’d modify the text to replace MLME-join to MLME-set as we are not using the Join function as it traditionally is in 11 and it will create confusion and comments so it’s best to create Set. We will need to add this primitive to Clause 10.
Meeting was recessed until PM 1 tomorrow.
TGp January 16, 2008 PM 1 (22 Attendees)
Meeting Minutes (continued)
Lee Armstrong began this session with a review of proposed updates to Clause 5. The progression he is proposing is form was it in D3.0 to what is proposed in 3.021 to what he describes in document 08 0164r0. The discussion was:
· Lee did not change the definition of WAVE BSS.
· He said a WAVE BSS is not an 802.11 BSS but there was disagreement within the group. Many think of a WAVE BSS as a special case of BSS.
· We don’t want to include a statement that WAVE Mode can’t use a BSS.
· Dick Roy again stated that a WAVE BSS does not exist and therefore we should remove it from this document.
· There was a discussion around mixing P1609 and 11p terminology and how that has led us into problems.
· Lee Armstrong stated that we are not getting rid of WAVE BSS and with the exception of Dick Roy there was agreement.
· Vinuth Rai tried to describe what the text is now saying and the two observations were A) Talk within a BSS and B) Talk outside a BSS.
· Daniel Jiang stated that we seem to agree on the behaviour of WAVE BSS but not on how to describe it. Dick again said it doesn’t exist.
· Daniel brought up that once a WAVE BSS is established the STA that initiated it can leave and the WAVE BSS will remain. There appeared to be consensus with this statement.
· Daniel and John will propose new text on the 1st paragraph in this section of Clause 5.
The discussion moved to sub clause 5.4.1.1
· John said that he didn’t understand the second sentence in this paragraph and he would like to check with an expert such as Justin McNew.
The discussion moved to sub clause 7.1.3.3.3
· We need to reword the first sentence to eliminate the word “field” and replace it with “frame”.
The discussion moved to sub clause 10.3.42.1.2
· It was not an oversight that WAVE BSS is not in this table. We don’t want this term in the table. We do not have WAVE BSS in the MLME-ONDEMANDBEACON.request table because it is not specific to WAVE BSS.
· Hanbyeog Cho pointed out that there appeared to be a mixing of the terms “indication” and “confirm”. Lee agreed and said they both should be there but they appeared mixed. He would check into this and straighten it out.
The discussion moved to sub clause 11.18
· Do we want to prevent a STA operating in WAVE Mode from joining and infrastructure BSS or IBSS?
· We are tying WAVE Mode to the MIB attribute. Is this testable? We are not sure but Peter Ecclesine stated that “untestable” things are made normative in other places in 11 so it is ok to do it here.
· There was a discussion on when a STA is in WAVE Mode you can’t join any BSS requiring association and authentication because you can’t do these in WAVE Mode. (Secretary’s Note: By definition this statement answers the first bullet in the notes on the discussion of 11.18 above.)
· Peter commented that we need to spell out that we send out data frames outside of a BSS. We didn’t do that in Draft D3.0.
· Peter says the MIB is not manageable and hasn’t been for 10 years. 11k has tried to address this (See Annex D).
· A concern was expressed by Dick Roy that if a STA in currently not operating in WAVE Mode and it needs to get a safety message it will miss this message. Others pointed out that a Wild Card BSSID can be used for safety messages if STA is not in WAVE Mode.
· Dick wanted to remove the 1st paragraph in 11.18 saying there was no reason to have it. There was not consensus on this suggestion.
· John Kenney noted that it appeared that there were parts missing in Lee’s submission, perhaps too much deleted. Lee agreed and will review.
· George Vlantis pointed out that this 1st paragraph should start out with “A STA in WAVE Mode” rather that “Operation in WAVE Mode. There was agreement and John and Lee agreed to work off line on coming up with a new proposal for this paragraph.