1 / 13

June 2010 J Moring

June 2010 J Moring. Status of Full Use WAVE Standards IEEE P1609.0, P1609.3, P1609.4, P1609.5. 1609.0/1609.5 Status. P1609.0 d0.9 posted April 2010 Adds Element ID annex to d0.8 posted June 2009 Excel spreadsheet posted for comments Soliciting input Objective: complete this year

jase
Download Presentation

June 2010 J Moring

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. June 2010J Moring Status of Full Use WAVE Standards IEEE P1609.0, P1609.3, P1609.4, P1609.5

  2. 1609.0/1609.5 Status • P1609.0 d0.9 posted April 2010 • Adds Element ID annex to d0.8 posted June 2009 • Excel spreadsheet posted for comments • Soliciting input • Objective: complete this year • P1609.5 remains dormant

  3. 1609.3/1609.4 milestones • New PARs approved March • Sponsor ballot 2010/3/19 – 2010/4/18 • ~63 balloters • ~92% response rate • ~92% approval rate • ~5% abstain rate • 158 comments on 1609.3 • 285 comments on 1609.4 • Held two sessions with comment resolution group, as well as individual coordination • Posted updated drafts and spreadsheets showing comment resolution • Recirculation (15 day) following June meeting • Required due to technical changes resulting from comments • August 8 deadline for September NESCOM/REVCOM meeting • Documents published October • Sponsor ballot approval criteria met: • 75% of registered voters must respond • 75% of actual votes affirmative

  4. 1609.3 comment summary • Treatment • 133 Accept or Accept Modified • 23 Reject • 2 Withdrawn • Category • 9 General • 61 Editorial • 88 Technical • “Must be approved” • 53 (9 Rejected, from 2 voters)

  5. 1609.4 comment summary • Treatment • 249 Accept or Accept Modified • 26 Reject • 10 Withdrawn • Category • 2 General • 141 Editorial • 142 Technical • “Must be approved” • 36 (3 Rejected, from 2 voters)

  6. Summary of changes • General • Corrections, clarifications, definitions, refinements • Sync with P802.11p D11, P802.11v, P802.11REVmb, P1609.2 d3 • Added unicast Timing Advertisement option • MIBs now mandatory • Added several MIB parameters, including entries for transmit parameters for management messages • Added Channel Identifier to WME-ManagementDataService request & indication, and VSA & TA indications • 1609.3 • New PSID format • Added WSA header extension WSA Count Threshold Interval • 1609.4 • Add new 1609.4 Annex for Guard Interval values • Honoring of Guard Interval on transmit by switching units now mandatory

  7. PSID format • The PSID is a variable length field, with the leading bit values indicating the length in octets as specified in Table 4. PSID value assignments will be maintained by the IEEE RAC outside this standard in the future. See http://standards.ieee.org/regauth/rac.html for latest assigned values and forms for requesting new values.

  8. Post-comment-resolution material • A Weinfield • Editorial • W Whyte • SSP • Editorial • A Malarky comments • Editorial • MIB organization: conformance groups • Other

  9. A Weinfield • Editorial • See email of June 4

  10. W Whyte • See emails of June 4 & June 5 • #SSP in WSA • *WSA verification • Editorial • in the clause 3.1, Definitions, of .3, we define PSID as "A number that identifies a service provided by a higher layer entity". Can we maybe change "number" to "field" or "octet string"? Or even "integer"? • # Additional changes in this area may be out of scope • * Need to associate with Sponsor Ballot comment, else out of scope

  11. A Malarky 1609.3 • 3.1 •  Control channel - disagree this intended just for WSAs and WSMs.  Don’t agree with changing "management information" to "WSA". •  Higher layer - I would delete the word entity.  There may be more than one "entity" comprising the functionality.  Also we have "higher layer traffic" in 6.2.3.1 and may be other "higher layer xxx". •  Service channel - delete "exchanges" at end of sentence •  Timing Advertisement frame - delete word WAVE. •  Vendor Specific Action frame - change "standardized WAVE management information" to "IEEE 1609 management information"   • 3.2  Add OSI • 5.5.3  Could add note stating passing received information to higher layers for WSMP WAVE Elements other than WAVE Short Message is defined in the associated references defined in Annex F. • 6.2.1  I still think you need a statement "The data rates and power levels for transmitting management messages are defined in IEEE P1609.4". • 8.2.3.6.6 - If new optional parameter is not present then no time bound on WSA Count Threshold.  (if someone picks up one per day is that enough ?)  I thought you were going to put a default value here ? • E.5 • 1)  PHY1 is tuned … Add "PHY2 is in default state - not assigned to any channel" • 4)  …PHY2 remains tuned…

  12. A Malarky 1609.4 • 2.0 Missing footnotes of where to get standards. • Should RFC 1042 be preceded by IETF ? • 3.1 Control channel - disagree this intended just for WSAs and WSMs.  Don’t agree with changing "management information" to "WSA".    • need to add higher layer • Service channel - delete "exchanges" at end of sentence • Timing Advertisement frame - delete word WAVE. •  Vendor Specific Action frame - change "standardized WAVE management information" to "IEEE 1609 management information" • 4.1 I would add sentences at end of first paragraph "To operate over multiple wireless channels while in operation with OCBEnabled, there is a need to perform channel coordination.  OCBEnabled indicates operation outside the context of a basic service set as specified in IEEE P802.11p (by setting dot11OCBEnabled to TRUE), i.e. WAVE operation."  this links multi-channel and channel coordination to lead into 2nd para, and also introduces OCBEnabled since this is the first time it is used in the standard.  It also resolves Malarky/18. • Add "for" or "in" after features in first sentence of 2nd para. • 5.3.1 I suggest add an editorial note (i.e. to IEEE editor) clarifying change from regulatory class to operating class.  Note 1st sentence is not strictly correct since 802.11p does not define or use operating class, however editorial note would clear this up. • 5.3.6 Add "routing of" to start of first and second paragraphs (current wording implies the information is specified). • 6.2.4 change "… along with the local time of reception Local Time, to determine the relationship between UTC and Local Time at a point in time, which can be used with Local Time to provide an estimate…" to " along with the local TSF time at reception Local Time, to determine the relationship between UTC and local TSF time at Local Time point in time, which can then be used with local TSF time to provide an estimate…" • 6.3.5 Add "or not" after boundary - whether requires two items • Annex A Missing footnotes of where to get standards. • Annex F Change "GPS" to "UTC" in 1st sentence of 2nd para.

  13. A Malarky MIBs • 1609.4 Annex E • *There is no defined 1609.4 version parameter to reference.  There possibly should be. • *There are few MIB parameters identifying capability (e.g. switching capable).  For remote interrogation there maybe should be. • There is an error in the MIB for Time Value-  it is not an integer.  Also don’t see need to split TimeError up into two items.  Make them both Object [Octet?] Strings with format as per 802.11p, Timing Capabilities=1. • *Suggest probably need to consider guidelines in RFC 4148 for MIBs.  May need to add conformance groups (applies to 1609.3 also).  Note 802.11mb has done this. • 1609.3 Annex B • *There are few MIB parameters identifying capability (e.g. WSMP capable).  For remote interrogation there maybe should be. • * Need reference to Sponsor Ballot comment, else out of scope

More Related