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

slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) PowerPoint Presentation
Download Presentation
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

play fullscreen
1 / 5
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
116 Views
Download Presentation
javan
Download Presentation

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Resolution of TG6 Draft D0 comment S7-40 and S7-221] Date Submitted: [3September, 2010] Source: [Ranjeet Kumar Patro] Company [Samsung Electronics] Address [Bagmane Lakeview, Block ´B´, No. 66/1, Bagmane Tech Park, C.V. Raman Nagar, Byrasandra, Bangalore, Karnataka, 560093, India] Voice:[+91 80 4181 9999], FAX: [+91 80 4181 9999], E-Mail:[rkp.atd@samsung.com] Re: [Proposed Resolution of D0 Comment S7-40 and S7-221] Abstract: [Description of document contents.] Purpose: [Description of what the author wants P802.15 to do with the information in the document.] 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. NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. <Ranjeet Kumar Patro>, <Samsung Electronics>

  2. Proposed Resolution of D0 CommentS7-40 and S7-221 <Ranjeet Kumar Patro>, <Samsung Electronics>

  3. D0 Comment S7-40 and S7-221 • Comment: Is this in essence time sharing as well? • Commentators proposed resolution: Merge this subclause with 7.12.3.1. Both are about time sharing, and may be supported by a common field encoded as "Allocation Percentage" in place of the "Allocation Time / duty cycle" field in the Coexistence Request/Response frames, which can be further combined into a single frame called "Command - Coexistence Time Sharing", as noted in another related comment. • Must be satisfied: Yes <Ranjeet Kumar Patro>, <Samsung Electronics>

  4. Proposed Resolutions • Resolution: Reject • Description: This comment has three parts: • Merging of two sections 7.12.3.1 and 7.12.3.2, • Merging of “Allocation Time / Duty cycle” field into one common name “Allocation Percentage” in the Coexistence Request/Response frames. • Merging of Coexistence Request/Response frames, which can be further combined into a single frame called "Command - Coexistence Time Sharing. • Explanation for A: It is better to keep the two sections separate. They cannot be merged as they are two distinctive techniques for coexistence. In time sharing method, the existing hub and prospective hub always have mutually exclusive time allocations. In offset piconet synchornization method, the existing hub and prospective hub may have overlapping time allocation which is possible in certain PHYs (e.g. UWB PHY). <author>, <company>

  5. Proposed Resolutions • Explanation for B: It is possible to combine and call them with one name “Allocation percentage”. However, coexistence request with the field representing “Allocation time” is most suited for time sharing method and the field representing “Duty Cycle” is most suited for offset piconet synchronization method. Moreover, it is gives a picture to standard implementer, about the distinction between the two coexistence methods. • Explanation for C: Coexistence Request/Response frames, cannot be combined into a single frame called "Coexistence Time Sharing”. How will hub distinguish between coexistence request from another hub and coexistence response to the coexistence request made to the same hub? Also, why it is required to optimize the two frames, when 251 command IDs are not utilized and reserved? <author>, <company>