1 / 17

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Suggested Text Generation Work Plan Date Submitted: September 2009 Source: Rick Roberts [Intel] Address: 2111 NE 25 th Ave, Hillsboro, Oregon 97124

alexismarquez
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Suggested Text Generation Work Plan Date Submitted: September 2009 Source: Rick Roberts [Intel] Address: 2111 NE 25th Ave, Hillsboro, Oregon 97124 Voice:503-712-5012, FAX: 503-264-3375, E-Mail: richard.d.roberts@intel.com Re: Abstract: Suggested work plan - submitted for committee approval and comment Purpose: Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Rick Roberts [Intel]

  2. What is a standard specification and what does it address? The standard normally says very little about the receiver implementation. A specification primarily addresses the air interface on the transmit side TX RX • The standard provides information and details to the implementer about the transmitted waveform. • PHY Preamble Training Waveforms • Modulation • Encoding • Header Field Definition • Individual Frame Formatting • Superframe Formatting (if one exist) • MAC command details • The standard does NOT tell the implementer how to use the above parameters to address a particular application deployment. Issues that deal with transmit power limits and safety limits are normally not addressed in the standard but rather reference is made to consult local regulatory limits. Rick Roberts [Intel]

  3. Compliance Testing Traditionally information regarding compliance testing is not part of an IEEE802.15 standard. Normally compliance testing documents are generated by industry support forums like the WiFi Alliance and are out of scope of the standard. An example of compliance testing is documenting signal processing waveforms at various points in the transmitter and/or receiver. It is not known at this time if there is a hard and fast rule in 802.15 in regards to compliance testing material being incorporated into an 802.15 standard. Rick Roberts [Intel]

  4. Robert’s Rules of Order Usage in Technical Editing It is pure coincidence that my last name is Roberts and we operate under Robert’s Rules of Order. In general I’d like to keep our editing sessions informal. That means if you want something then ask for it, the committee can discuss it informally and then to gauge opinion we can ask for a nonbinding straw vote. If things get continuous we can operate under Robert’s rules which is more formal and is based upon making motions, which are seconded, discussed, amended and then approved or disapproved based upon a formal vote. Anytime we are operating under Robert’s rules I’ll make sure I explain what is happening and suggest the procedure to follow so that things operate smoothly. Remember … the end of the most continuous day in IEEE802.15.7 we should still exit the room as friends, so please try to “keep your cool”. Rick Roberts [Intel]

  5. Robert’s Rules of Order Usage in Technical Editing (continued) I’d like to generate draft text in an informal, inclusive, manner … which means not everyone is going to agree upon all the text that is in an unapproved draft of a document. But technical documents under go periodic technical voting to stabilize or change the technical content of a technical document. Technical votes require a 75% approval, which is intentionally set high so as to indicate strong technical agreement within the committee. Once the unapproved draft is done I’ll make a motion to ask for a technical vote to approve the content of the document. The motion will have to be seconded and then the discussion starts on the motion. This can include amendments to the motion such as asking that text be excluded and/or included from the document under consideration. After we have exhausted the discussion and amendments then we complete the vote and the document is approved or not. Once approved the content of the document can only be changed by another technical vote. Rick Roberts [Intel]

  6. Work Load IEEE802.15.7 is chartered to write a PHY and MAC standard. What may be the percentage workload given the various topics to address? Using the IEEE802.15.4 document as an example … the total amount of normative text in 805.15.4 is roughly 217 pages. General Descriptive Text ... 38 pages (17%) PHY Related Text ……….. 26 pages (12%) MAC Related Text ………. 132 pages (61%) Annexes ………………….. 22 pages (10%) So if these percentages hold for 802.15.7 then most of our time will be spent working on the MAC. Total amount of text that discusses the receiver … 1 page (0.5%) Rick Roberts [Intel]

  7. Assumptions based upon email discussions and suggested way to go forth … • IEEE802.15.7 is moving away from the confrontational down selection vote and more towards an inclusive text generation process. • Proposed first step is the generation of a comprehensive outline for the document which highlights technical topics that we agree need to be included in the document. • We then solicit text for each of these technical topics against a published schedule that is agreed upon within the committee. • As we fill in each topic we have a technical vote (conducted at the next TG7 meeting) to include the text into the document, after which changing the text requires a technical vote. • Once we fill in all the technical topics we will have a technical vote approved document. • We then solicit comments on the whole document and go through an internal comment resolution process prior to submitting the document to WG15. Rick Roberts [Intel]

  8. CONTENTS • 1. Overview • 2. References • 3. Definitions • 4. Acronyms and abbreviations • 5. General description (16 pages in 15.4) • 5.1 Network description • 5.2 PHY description • 5.3 MAC description • 5.4 Functional Overview • 6. PHY specification (26 pages in 15.4) • 6.1 General requirements and definitions • 6.2 PHY service specifications • 6.3 PPDU format • 6.4 PHY constants and PIB attributes • 6.5 High Rate PHY specifications • 6.6 Low Rate PHY specifications • 6.7 General PHY specifications • 7. MAC sublayer specification (132 pages in 15.4) • 7.1 MAC sublayer service specification • 7.2 MAC frame formats • 7.3 MAC command frames • 7.4 MAC constants and PIB attributes • 7.5 MAC functional description • 7.6 Security suite specifications • 7.7 Message sequence charts illustrating MAC-PHY interaction • Annexes (482 pages in 15.4) See 802.15.4 for an example Suggest we do this first so the committee agrees on a high level description Subject to committee approval Rick Roberts [Intel]

  9. Current Schedule Date of stable draft Unfortunately, as shown in this document, it is believed that we’ll need to slip the schedule by one meeting due to the work load. The proposed objectives by meeting are shown below. Objectives by meeting … 1. September meeting: agreement upon general description and document outline 2. November meeting: continue text editing and draft text approval 3. January meeting: complete text editing and start internal comment reviews of complete text 3. March final draft agreed upon by 802.15.7 and motion made in WG to initiate letter ballot Rick Roberts [Intel]

  10. Proposed Modified Timeline Based Upon Projected Workload Date of stable draft Objectives by meeting … 1. September meeting: agreement upon general description and document outline 2. November meeting: continue text editing and draft text approval 3. January meeting: complete text editing and start internal comment reviews of complete text 3. March final draft agreed upon by 802.15.7 and motion made in WG to initiate letter ballot Rick Roberts [Intel]

  11. This can be done via either a single merged proposal or, lacking a single merged proposal, this can be done via motions and voting. High Level Schedule Rick Roberts [Intel]

  12. ConCall #3 IEEE802 ConCall #1 IEEE802 Travel and Week Off ConCall #2 Travel and Week Off ConCall #4 ConCall #5 IEEE802 Holiday and New Years Pragmatically, we have time for 5 conference calls from September to January assuming a conference call every two weeks. Rick Roberts [Intel]

  13. Detailed PHY Schedule Rick Roberts [Intel]

  14. Detailed MAC Schedule Rick Roberts [Intel]

  15. Remember The job of the editor is to edit the text that is submitted by the committee. It is not the editors job to originate text. The committee can submit text in just about any format: • Power Point • Word • Email Rick Roberts [Intel]

  16. Motion (procedural) … The committee adopts the work plan as outlined in document XYZ, subject to end date adjustments as necessary to complete the work. 1St : Rick Roberts 2nd : Yes: No: Abstain: Rick Roberts [Intel]

  17. The End – Questions Rick Roberts [Intel]

More Related