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

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Draft 2 group addressing text synopsis] Date Submitted: [17 March, 2005] Source: [Robert Cragie] Company [Jennic Ltd.] Address [Furnival Street, Sheffield, S1 4QT, UK] Voice:[+44 114 281 4512], FAX: [+44 114 281 2951], EMail:[rcc@jennic.com] Re: [Response to the call for proposal of IEEE 802.15.4b] Abstract: [Discussion for several potential enhancements for current IEEE 802.15.4 MAC] Purpose: [For the discussion at IEEE 802.15.4b Study Group] 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. Robert Cragie, Jennic Ltd.

2. Draft 2 group addressing text synopsis Robert Cragie Jennic Limited Robert Cragie, Jennic Ltd.

3. Introduction • A synopsis of the text which will be in draft 2 outlining the content of the sections with regard to group addressing • Based on discussions between members of a subgroup consisting of: • Phil Beecher, CompXs • Robert Cragie, Jennic • Øyvind Janbu, Chipcon • Joseph Soma Reddy, Figure 8 Wireless • Zachary Smith, Ember • Rene Struik, Certicom Robert Cragie, Jennic Ltd.

4. Background • Document 15-05-0169-00 • Draft 1; all section, figure and table references refer to Draft 1 • Document 15-05-0134-01 is a proposal for a change in auxiliary security header which would accommodate the proposals in this document • Acceptance of this document as the basis for group addressing text does not imply that document 15-05-0134-01 will also be accepted • Additional points follow Robert Cragie, Jennic Ltd.

5. Group addressing only for data frames • Beacon is implicitly broadcast and contains no destination address, so is not eligible for group addressing • Ack contains no destination address, so is not eligible for group addressing • Currently only two command frames which use broadcast: • Beacon request • Coordinator realignment • Both command frames need to be implicitly broadcast because of their nature • If they need to be secured, explicit key identifier can be used • The mechanism proposed must however not be restricted to data frames as it is conceivable that all frame types in future revisions may be eligible for group addressing Robert Cragie, Jennic Ltd.

6. Addressing modes • Use of group addressing bit redefines the meaning of the destination address • Current proposal is to use destination address modes 2 and 3 for group addressing, i.e. this would allow 16-bit and 64-bit group identifiers • Current proposal is to exclude the use of destination address modes 0 and 1 for group addressing • Questionable whether a 64-bit group would ever be used due to excessive storage and frame occupation, however one case has been identified where a 64-bit address of a device originating a key is used as its identifier Robert Cragie, Jennic Ltd.

7. LB28 comments • There are a number of comments for LB28 referring to draft 1 group addressing text which need to be addressed • Naturally the outcome of these comments will also affect the resulting text Robert Cragie, Jennic Ltd.

8. Section 7.1 MAC sublayer service specification • No need to consider current MLME primitives as group addressing applies to data frames only • Currently supports all the parameters required for group addressing: • MCPS-DATA.request TxOptions parameter contains group addressing bit (change option to 0x10, not 0x08) • MCPS-DATA.indication contains GrpAddress parameter • For security process, additional group sequence number can be passed through KeyIdAddress (KeyIdentifier) (see also 15-05-0134-01) • May need to add address mode checking for MCPS-DATA.request Robert Cragie, Jennic Ltd.

9. Section 7.2 MAC frame format • Figure 35 already supports group addressing • Section 7.2.1.1.6 already supports group addressing • Table 66 will need revising for group addressing support • Sections describing addressing modes will need revising for group addressing support • Section 7.2.2.2.1 probably supports group addressing sufficiently Robert Cragie, Jennic Ltd.

10. Section 7.2 MAC frame format (2) • Need to ensure frame types other than data frame clearly show group addressing bit is set to 0 • Need to specify that data frames using group addressing shall not be acknowledged Robert Cragie, Jennic Ltd.

11. Section 7.3 MAC command frames • Draft 1 text supports group addressing in the sense that group addressing does not apply to command frames • Need to ensure text is there which states that group addressing bit is set to zero Robert Cragie, Jennic Ltd.

12. Section 7.4 MAC constants and PIB attributes • Need to add definition of Destination Address Filter Table (DAFT)  • Format not decided but will be a lookup table with the same operation in essence as DeviceTable and KeyTable. • The lookup operations of DeviceTable and KeyTable are comprehensively described in 7.5.8 • Could be simplified if address mode is restricted to mode 2 only, i.e. 16-bit only Robert Cragie, Jennic Ltd.

13. Section 7.4 MAC constants and PIB attributes (2) • DAFT needs to be optional • Logical solution is to have a boolean PIB attribute, e.g. macDestFilterTableEnabled: • FALSE – no destination address filtering is applied • TRUE – destination address filtering is applied according to section X.X • Default : FALSE • Alternative 1: Default is to have zero entries, and that zero entries means no destination address filtering is applied, i.e. a ‘wildcard’ and all data frames are passed for further processing Robert Cragie, Jennic Ltd.

14. Section 7.4 MAC constants and PIB attributes (3) • Alternative 2: Default is to have zero entries, and that zero entries means all group addressed frames are silently discarded. • This would mean the mechanism to set up the DAFT would be done using unicast frames Robert Cragie, Jennic Ltd.

15. Section 7.5.6.1 Transmission • Will need revising to accommodate group addressing Robert Cragie, Jennic Ltd.

16. Section 7.5.6.2 Reception and rejection • Need to add text to clarify that if the group addressing bit is set, the (data) frame should be processed according to the section which describes using the destination address filter table • This section is missing and needs to be added but doesn’t necessarily fit into this section • Suggest using the format used in 7.5.8 which although arguably terse, is precise and unambiguous Robert Cragie, Jennic Ltd.

17. Section 7.5.6.4 Use of acknowledgements • Need to specify that group addressed data frames are not acknowledged • This may not be the section to do it in but it should be referenced here Robert Cragie, Jennic Ltd.

18. Section 7.5.8 Frame security • Section 7.5.8.3.2 and 7.5.8.3.4 need to include text to accommodate the implicit key lookup based on group address if group addressing is specified • There will also be a single key sequence number accommodated in a single octet KeyIdAddress (KeyIdentifier) field which is used in addition to the group address for key lookup Robert Cragie, Jennic Ltd.