1 / 7

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: Recommended Practice Draft Document Status January 2014 Date Submitted: January 20 th , 2014 Source: Paul Chilton Company : NXP Semiconductors Address Furnival Street, Sheffield, S Yorks UK

verne
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. Paul Chilton, NXP Semiconductors Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Recommended Practice Draft Document Status January 2014 Date Submitted: January 20th , 2014 Source: Paul Chilton Company: NXP Semiconductors Address Furnival Street, Sheffield, S Yorks UK Voice:+44 (114) 281 2655 e-mail: paul.chilton@nxp.com Re: KMP Recommended Practice predraft Abstract: Summary of status of predraft document. Purpose: To describe the status of the document and highlight areas which need further work 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.

  2. Paul Chilton, NXP Semiconductors Los Angeles, CA January 20, 2014 TG9 KMP Document Statusand further work

  3. Paul Chilton, NXP Semiconductors Document Status • We are now following 802.15 rules • Now stored in private area of document server • Access for voting members of 802.15 using username and password • Anyone contributing or reviewing but not a member of 802.15 see me • Naming convention has changed • Document when released to review is a Draft ie d01 etc • Prior to this (where we are) the doc is a predraft • Doc now named accordingly – latest is • predraft5_P802-15-9_Draft_Standard.pdf

  4. Paul Chilton, NXP Semiconductors Changes since predraft4 • Acted on review comments received on predraft4 • Added Annex A – 802.1X text • Thanks to Brian et al for providing • Trawl through the document • Correct editorials, clean up language and diagrams • BUT now there are so many changes, change bars will be of little use, so • Predraft5 released with no change bars • It still needs people to review • I may have not understood something and altered the meaning by my edits

  5. Paul Chilton, NXP Semiconductors Todo List • Complete the primitives for using the KMP transport service • Define the operations and parameters • Text to describe them • Sequence Diagrams • Security PIB elements (eg macRekey etc) • Remaining text for Annexes • Check and correct formatting

  6. Paul Chilton, NXP Semiconductors Some thoughts • Separate KMP transport service from MAC • Don’t add commands into MAC, define separate KMP management layer • Eg KLME-Start.request • Even more radical • Separate KMP transport from the fragmentation and reassembly • Fragmentation service becomes general purpose for use by other services which need to transport frames larger than MAC • KMP uses fragmentation service • FLME-Data.request, FMLE-Data.indication etc • May make it easier to implement KMP operations by hiding the fragmentation mechanism

  7. Paul Chilton, NXP Semiconductors Some more thoughts • Should we test the design by trial implementations of some of the KMPs? • Checks that the services and parameters are adequate • Provide a reference implementation for the KMP • Do we need an explanation of the 802.15.4 and 15.7 security? • Implementors can see what security PIB information needs to be filled in by their KMP

More Related