doc IEEE 802 15 10 0664 00 0006

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG 6 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 D 0 Comments S 6 -453, S 6 -454, S 6 -455, S 6 -456, S 6 -457, S 6 -458, S 6 -459 Abstract: This document addresses the following comments [S 6 -453, S 6 -454, S 6 -455, S 6 -456, S 6 -457, S 6 -458, S 6 -459] in the TG 6 MAC draft D 01 and proposes resolutions Purpose: This document is for the MAC comment resolution discussion for TG 6 draft D 01 Notice: This document has been prepared to assist the IEEE P 802. 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 P 802. 15. Submission 1 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Proposed Resolution of D 0 Comments [S 6 -453, S 6 -454, S 6 -455, S 6 -456, S 6 -457, S 6 -458, S 6 -459] Submission 2 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 D 0 Comment S 6 -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 RAP 1 for access and uses the beacon to synchronize before contending in RAP 1. 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. Submission 3 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Additional comments - S 6 -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 mperiodic 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 Submission 4 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Alternative Resolutions - S 6 -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. Submission 5 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Proposed Resolution - S 6 -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. Submission 6 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 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) Submission 7 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 D 0 Comment S 6 -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!). Submission 8 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Proposed Resolution - S 6 -453 • Reject: – The existing draft already allows an application to define its own protocol independent of the MAC layer Submission 9 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 D 0 Comment S 6 -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 Submission 10 O Omeni, Toumaz UK. Ltd.

doc. : IEEE 802. 15 -10 -0664 -00 -0006 September, 2010 Proposed Resolution - S 6 -399 • Add an IE for this field so that it can be optionally included as needed. Submission 11 O Omeni, Toumaz UK. Ltd.