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: [Different Frame Formats Analyses in Current 15.4E std Draft] Date Submitted: [Jan. 11, 2010] Source: Author [Yang Yang, HeQing Huang, HaiTao Liu, Liang Li, Jie Shen][SIMIT/Vinno/Huawei] Address [No.865 Changning Road, Shanghai, 200050, China] Voice:[+86-021-6251-1070], FAX: [+86-021-6213-2314], E-Mail:[youcyyang@gmail.com] Re:[IEEE P802.15.4e] Abstract: [This document analyzes the current frame formats in different MAC proposals of 802.15.4e, and indicates the places need to be discussed.] Purpose: [Discussion in 802.15.4e Task 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.

2. Purpose of Propose • Provide the direct comparison for all of Proposed Formats • List the missed definition and unclear explanation • Try to suggest the united formats

3. Things we should discuss • Necessity of each field in different frames • Some fields are not necessary • Some fields are absent, according to the corresponding function description • Compatibility of different frame formats • Different application requirements result in different frame formats, but they should be identifiable (can be identified by the receiver) and compatible (comply with the same basic principle)

4. Acronyms and abbreviations • LL • Low latency • PA • Process automation • CM • Commercial • FA • Factory automation • LE • Low Energy

5. CM Frame Format --- Beacon frame EGTS Superframe Specification field Channel Hopping Specification field Time Synchronization Specification field Beacon Bitmap field

6. EGTS Frame Format --- Acknowledgement frame The length of each field haven’t been defined. • PAN ID • Identify the PAN of the transmitting coordinator • Source ID

7. CM Frame Format --- Command frame The CM-Association request command is not listed in table 123. It should be the type as a new one into table 123, or just choose to modify all the association request command (0x01 in table 123) to this format. Same problems with the CM-Association request command • CM-Association request command • Capability Information field • CM-Association respond command

8. CM Frame Format --- Command frame • EGTS handshake command • EGTS Characteristics fields • EGTS Descriptor field • EGTS ABT Specification field

9. CM Frame Format --- Command frame • EGTS information request command • EGTS information reply command • Beacon allocation notification command • Beacon collision notification command • Link status report command

10. CM Frame Format --- Command frame Need to be added. • Multi-channel beacon request command • Multi-channel hello command • Hello Specification field • Multi-channel hello reply command • Channel probe command • Channel Probe Specification field

11. CM Frame Format --- Beacon frame [youcy1]In 15.4, all the subfields indicating the timeslot in different frame are 4 bits in length, but why the length of the ECFP Start Slot subfield is variable? The Frame Version subfield, 0x10 to indicate an CM frame Add these fields in previous 15.4 beacon frame format. The frame format of PA frame and CM frame are both use the base frame format and the same MHR defined in 15.4-2006, if the Frame Version subfield in Frame Control field set to 0x10 to indicate an CM frame, then which value will indicate PA frame?

12. LL Frame Format in 15.4, the Frame Version subfield is 2 bits in length and 0x00 indicates a frame compatible with IEEE Std 802.15.4-2003, 0x01 indicates an IEEE Std 802.15.4-2006 frame. So we should add this field in the frame format. Don’t have the Sequence Number field, how to maintenance the acknowledgement and retransmission mechanism? • 1 octet MHR • Frame Type subfield set to 100 to indicate this type of frame • Frame Version subfield is 1 bit in length • set to 0 to indicate a frame compatible with IEEE Std 802.15.4-2006 and newer editions • Auxiliary Security Header field of the MHR shall be present if the Security Enabled subfield is set to one

13. LL Frame Format --- Beacon frame according to the description about this field, the value of this field indicates the length of the data frame payload, but the name of "Timeslot Size" is so confused. as the Actuator Direction field is only 1 bit in length, the actuator slots will be all downlink or uplink, can we set the configuration of it’s direction more flexible?

14. LL Frame Format --- Beacon frame As the value of macFAnumTimeSlots can be configured in the Number of Base Timeslots in Superframe field, the number of bits of the Group Acknowledgement field is variable. If this value is not multiples of 8, how to deal with this situation? can’t find any configuration about which slots will be shared group time slot in Beacon frame, neither in Configuration Request frame, but this configuration is necessary, as only in the shared group time slot and management time slot, the device should perform CSMA before transmit a frame to the coordinator, which is different from other time slots. how to acknowledge the retransmit data frame in the retransmission time slots? • Group Acknowledgement field • The Group Acknowledgement field is a bitmap of length (macFAnumTimeSlots – macFAnumRetransmitTS) bits • If the data frame has been received during a shared group time slot, all corresponding bits of this shared group time slot will be set accordingly in the Group Acknowledgement bitmap • The Group Acknowledgement field contains a bit field where each bit corresponds to a time slot associated with a sensor device or an actuator device excluding retransmission time slots

15. LL Frame Format from the description of different modes of LL network, the discover response frame/ configuration request frame all need separate Acknowledgement frame, and the data send by coordinator should be acknowledged by separate Acknowledgement frame send by sensor in the next superframe. But can't find the definition of the Acknowledgement frame format for LL network. These types are wrong, as the discover response frame and configuration request frame both are command frame Data frame Acknowledgement frame

16. LL Frame Format --- Acknowledgement frame Is this field necessary? how to acknowledge the retransmit data frame in the retransmission time slots? Can’t find any fields in the shortened MHR or other places of the data frame, which can indicate the frame need acknowledged in beacon frame or by a separate group acknowledgement frame. • Acknowledgement payload • Source ID identify the transmitting LL_NW PAN coordinator • Same problem with the Group Acknowledgement field in Beacon frame

17. LL Frame Format --- Command frame In the draft, three types of command frame payload are defined to can be used in both MAC command frame and shortened MAC command frame, but maybe these payloads can be only useful in LL network, so maybe don’t need to set these both available in the normal MAC command frame. • Discover Response command payload • Full MAC address • Required time slot duration • Sensor/ actuator type indicator • Configuration Response command payload • full MAC address • short MAC address • required time slot duration • sensor / actuator • assigned time slots • Configuration Request command payload

18. LL Superframe Configuration • This field “contains an integer number that identifies together with the Gateway ID the current configuration” • Is this field is necessary? • If it’s necessary, there isn’t any operation to link the current configuration to a sequence number, neither in the beacon frame or the configuration request frame. Need be discussed: which parameter should be configured in beacon frame, and which should be configured in configuration request frame? how to choose will be better? • Configured by Beacon frame • actuator direction • number of base timeslots per management timeslot • configuration sequence number • base timeslot length • number of Base timeslots in superframe • Configured by Configuration Request frame • transmission channel • existence of management frames • time slot duration • assigned time slots

19. Octets Octets Octets : : : 1 1 1 1 1 1 1 1 Short Short Command Command Command Originator Network ID Network ID Destination Network ID Frame Identifier Frame Identifier Frame Identifier ( see Table123 ( ( see Table 123 see Table 123) Address Address LL Frame Format --- Command frame These three command frames are used to make data transmit from device to coordinator in the shared time slot reliable. • Clear to Send Shared Group Frame • Request to Send Frame • Devices are requested to be capable of transmitting and receiving this command • Clear to Send Frame

20. PA Frame Formats --- Acknowledgement frame can’t find definition of this subfield not recognize this as an ACK? in 15.4, if the Destination Addressing Mode subfield is equal to zero and the Frame Type subfield does not specify that this frame is an acknowledgment or beacon frame, the Source Addressing Mode subfield shall benonzero. The frame type shall be ACK (0x010) or “data”, which should be discussed, and how to differentiate this formats from the corresponding formats in 15.4-2006? • a subset of the Extended ACK definition • some fields are virtual, used in creating the MMIC but not actually transmitted • Frame control attributes for ACK/NACKs: • frame type shall be data • security shall be disabled, as it is handled in the DHR • Frame version shall be 0x10 • Source Addressing Mode shall be 0x00, Destination Addressing Mode shall be 0x00

21. PA Frame Formats --- Acknowledgement frame Why not just maintenance this as a PIB parameter locally, why should set this as a virtual field of the acknowledgement frame? Please define the DPDU’s format DHR format • Echoed MMIC of received DPDU is a virtual field, used to calculate the ACK/NACK’s MMIC, but not transmitted • The acknowledgers EUI-64 shall be included in the source address field of the ACK/NACKs MHR if so requested in the received DPDU’s.

22. PA Frame Formats --- Acknowledgement frame • Absent definition • MMIC • EUI-64 • DPDU format • Auxiliary sub-header field • Absent description • Explicit Congestion Notification (ECN) • How to handling the virtual field of “Echoed MMIC of Received DPDU” • DL protocol • Slow hopping period • Message queue congestion and forwarding problems along the route

23. PA Frame Format --- Command frame • Advertisement command • Security Control field • Join Control field • Timeslot Template and Hopping Sequence ID field • Slotframe Information and Links (for each slotframe) field

24. PA Frame Format --- Command frame Can’t find clearly description about this subfield. • Join command • Clock Accuracy Capability field • Neighbor field Active command

25. SUN Frame Format --- Command frame • SUN-Enhanced Beacon request command • Request Field There defined some SUN-commands, which are not listed in Table 123, and can't find any function description about the SUN devices or network.

26. LE Frame Format --- Command frame • Wakeup command • The reserved FCF reserved bit 7 is renamed to the CSL sync bit, when the bit is set to 1, a 4-octet optional CSL sync field is added to the end of the current MHR • Secure Acknowledgement Frame The Wakeup frame is not listed in Table 123, either not adopt the general MAC command frame format (there don't have the command identifier field to distinguish this type of frame from other command frames). This type of Acknowledgement Frame is a subtype of LE command frame? If not, how to distinguish this type? About the fields setting, compare with the PA Acknowledgement frame, and discuss.

27. Thank you