doc.: IEEE 802.15-<doc#15-10-0664-00-0006> <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG6 MAC comments resolution proposal Date Submitted: 06 September, 2010 Source: Okundu Omeni Company: Toumaz UK, Ltd Address: 115 Milton Park, Abingdon, Oxfordshire, UK Voice: 01235438966, FAX: 01235438970, E-Mail: okundu.omeni@toumaz.com Re: Proposed Resolution of D0 Comments S6-453, S6-454, S6-455, S6-456, S6-457, S6-458, S6-459 Abstract: This document addresses the following comments [S6-453, S6-454, S6-455, S6-456, S6-457, S6-458, S6-459] in the TG6 MAC draft D01 and proposes resolutions Purpose: This document is for the MAC comment resolution discussion for TG6 draft D01 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. O Omeni, Toumaz UK. Ltd. <author>, <company>

September, 2010 Proposed Resolution of D0 Comments [S6-453, S6-454, S6-455, S6-456, S6-457, S6-458, S6-459] O Omeni, Toumaz UK. Ltd.

doc.: IEEE 802.15-<doc#15-10-0664-00-0006> <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 D0 Comment S6-453 Original comment: The current specification of this field can create ambiguity about whether a future superframe is active or not. For example a low duty cycle node wants to use RAP1 for access and uses the beacon to synchronize before contending in RAP1. if it hears a beacon without an inactive duration, it could assume that every superframe is active, but could find that the next beacon indicated there would be a number of subsequent inactive superframes. Proposed resolution this field should be used to indicate the next guaranteed active superframe and another bit (we can use the relay bit in the MAC header for this) used to indicate if the next superframe would be active or not. O Omeni, Toumaz UK. Ltd. <author>, <company>

Additional comments - S6-453 <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Additional comments - S6-453 The dilemma here is that we want to have a flexible number of active & inactive superframes, but only want to use 1 field to represent this. Based on initial discussions, the understanding was that we would only have 1 active superframe followed by N inactive super frames. This restriction makes it possible for the active superframe boundaries to be clearly defined and removes restrictions on m-periodic traffic. If we want to have the flexibility of M active superframes followed by N inactive superframes, this puts restrictions on the types of m-periodic traffic that can be supported. Solely based on the factorization of the required m into the active/inactive cycle. This would also make it almost impossible (or quite complex) for a hub to allocate periodic traffic reliably. To represent this with just 1 field creates problems for power constrained nodes as they would always need to listen to all beacons I also question the applicability of M active + N inactive superframe scenario. This doesn’t fit into periodic traffic O Omeni, Toumaz UK. Ltd. <author>, <company>

Alternative Resolutions - S6-453 <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Alternative Resolutions - S6-453 this field (inactive duration) should be used to indicate the next active superframe following the inactive superframes and another the relay bit in the MAC header used to indicate if the next superframe would be active or not. We would also need to change the coexistence bit for inactive superframes in figure 11 to “inactive superframes enabled” and edit the text accordingly. The issue with this resolution is that a node cannot know how many active superframes there are. Add another field to indicate the number of active superframes following the current active superframe. The number of active superframes field would count down until the last active superframe. We would also need to change the coexistence bit for inactive superframes in figure 11 to “inactive superframes enabled” and edit the text accordingly. Since this field would only be present when inactive superframes are being used, it doesn’t burden the beacon with unnecessary bytes when they are not needed. We restrict this to 1 active superframe followed by N inactive superframes. So this field should be renamed to number of inactive superframes and the text rewritten accordingly. We would also need to change the coexistence bit for inactive superframes in figure 11 to “inactive superframes enabled” and edit the text accordingly. O Omeni, Toumaz UK. Ltd. <author>, <company>

Proposed Resolution - S6-453 <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Proposed Resolution - S6-453 We restrict this to 1 active superframe followed by N inactive superframes. So this field should be renamed to number of inactive superframes and the text rewritten accordingly. We would also need to change the coexistence bit for inactive superframes in figure 11 to “inactive superframes enabled” and edit the text accordingly. This is preferred because it simplifies the implementation and allows this mechanism to be used for all types of periodic traffic. O Omeni, Toumaz UK. Ltd. <author>, <company>

doc.: IEEE 802.15-<doc#15-10-0664-00-0006> <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Proposed Resolution (Provide details of the proposed resolution) (Provide sketch or figures as necessary to illustrate the proposed resolution) O Omeni, Toumaz UK. Ltd. <author>, <company>

doc.: IEEE 802.15-<doc#15-10-0664-00-0006> <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 D0 Comment S6-446 Original comment: (TR) Clause 6.3.2.3.1, p. 32, Table 5: This suggests that the particular protocols for a fixed field value are fixed (and as defined in Clause 8, with only 80-bit crypto strength). What about algorithm agility here? Why is there no public-key based authenticated key agreement scheme with certificates? What about a proper symmetric-key based authenticated key agreement scheme? Suggested remedy: allow much more flexibility in terms of schemes supported (algorithm agility!). Proposed resolution Suggested remedy: allow much more flexibility in terms of schemes supported (algorithm agility!). O Omeni, Toumaz UK. Ltd. <author>, <company>

Proposed Resolution - S6-453 <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Proposed Resolution - S6-453 Reject: The existing draft already allows an application to define its own protocol independent of the MAC layer O Omeni, Toumaz UK. Ltd. <author>, <company>

doc.: IEEE 802.15-<doc#15-10-0664-00-0006> <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 D0 Comment S6-399 Original comment: What is Former Hub Address to be used for? Proposed resolution Need to add a section on the role of this field and suggest making it optional O Omeni, Toumaz UK. Ltd. <author>, <company>

Proposed Resolution - S6-399 <month year> doc.: IEEE 802.15-<doc#15-10-0664-00-0006> September, 2010 Proposed Resolution - S6-399 Add an IE for this field so that it can be optionally included as needed. O Omeni, Toumaz UK. Ltd. <author>, <company>