1. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [MAC Clarifications and Questions] Date Submitted: [July 13, 2004] Source: [Robert Poor, Lee Taylor] Company [Ember Corporation] Address [313 Congress Street, Boston MA 02210] Voice:[+1 617 951-0200], FAX: [+1 617 951-0999], EMail:[rpoor@ieee.org] Re: [Response to the call for proposal of IEEE 802.15.4b, Doc Number: 15-04-0239-00-004b.] Abstract:[Clarifications and open questions regarding the current IEEE 802.15.4 MAC] Purpose:[Proposal to IEEE 802.15.4b 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. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 2 MAC Clarifications and Questions Robert Poor Lee Taylor

3. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 3 Support of Protocol Identifier The 15.4 spec would be more useful if it supported a protocol identifier byte. There is no easy way to differentiate ZigBee frames (e.g.) from other network frames running on top of 15.4. Ensuring validity of any protocol by checking header bits alone is not necessarily enough. One possible solution would be to reserve the first byte of the MAC payload for this purpose. Administration of the identifier byte is open for discussion.

4. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 4 Interpreting turnaround time Interpretation of turnaround time is ambiguous. For example, when sending an ack in unslotted mode, the ack is to commence transmission 12 symbols after the reception of the packet. Presumably since this 12 symbols is based on the phy aTurnaroundTime constant, it is meant to allow time for the radios to turnaround, and the first byte of the preamble should be transmitted 12 symbols after the reception. However, if this is the case it is unclear what would happen in slotted mode, where the ack is to wait for the next backoff boundary. Should the turnaround commence in advance of the backoff boundary, to send the first preamble on the boundary, or should turnaround itself commence on the boundary, delaying the first preamble byte to later? A similar question holds when sending beacons, and regular packets with csma in slotted mode. These are both to commence on backoff boundaries, but it is unclear whether turnaround is supposed to start prior to, or at the boundary. Presumably, since these transmissions occur by sending a PD-DATA.request to the phy at the boundary, the turnaround starts after the boundary.

5. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 5 Overlapping Beacons There is no described facility to coordinate the transmission of beacons by multiple devices on the same channel and within range of each other. This could potentially be satisfied with specification of additional black-out periods in the superframe at least after the transmission, and perhaps also prior to the transmission of the beacon itself (prior to is not strictly required, since the inactive portion of the superframe could be utilized. Using this additional parameter, multiple beaconing devices could at least choose to arrange their beacons such that they will not collide with each other and their respective portions of the superframe. It would be the responsibility of the higher layers to handle the coordination. Along with this, a start time would have to be able to be specified in the MLME- START.request primitive. The start time should be kept relative to the timestamp of other received beacons.

6. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 6 Section 6.7.9: CCA CCA detection time is listed as 8 symbols, however whether averaging or peak detection should be employed is not discussed. Should be clearly discussed that the CCA is to BEGIN on the request, last for the next 8 symbols, then terminate. This distinction becomes very important when performing slotted mode CSMA. CCA Mode 3 (Carrier sense AND energy above thresh) is essentially no better than CCA Mode 2 (Carrier sense only) In fact it almost guarantees worse performance because CCA could return clear even when a weak packet is being heard, quite possibly leading to additional collisions, especially when hidden terminals are taken into account. Ideally there should be a mode allowing for carrier sense OR energy above thresh.

7. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 7 Section 7.5.1.2: Inter-frame spacing Inter-frame spacing as defined is essentially unenforceable. It only works when there are two nodes on a network communicating with each other. If one node transmits multiple packets to the other node, it can ensure that it waits long enough to obey the spacing. However, due to hidden terminal issues, once more than 2 nodes are both trying to communicate with a third, all bets are off. In unslotted networks, the CSMA algorithm does not attempt to take the inter frame spacing into account. On slotted networks, it attempts to enforce it by checking for CCA on two backoff boundaries in a row, but that also does not work.

8. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 8 Section 7.5.1.3: CSMA algorithm In slotted mode, the algorithm seems to assume that by doing CCA checks on backoff boundaries, it will also detect transmissions that begin on those boundaries as well, and return CCA busy. This is a common race condition, unless the turnaround of a transmitter has actually commenced in advance of a backoff boundary in preparation for the first byte of preamble to be sent on the boundary. (Arguably that could still be a race condition depending on how the PA ramps, the CCA mode, etc.) Requiring that frames received during a CCA operation be discarded (5th paragraph) appears to be an error. Perhaps this was meant to be optional to allow for simplified CCA mechanisms in some implementations?

9. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 9 Section 7.5.2.1.4: Orphan Scan Second paragraph states that if a coordinator realignment command is successfully received in time, the device shall disable its receiver. Is it really required that the coordinator disable its receiver?

10. doc.: IEEE 802.15-04-0363-00-004b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 10 Section 7.5.6.5: Retransmissions It is ambiguous whether or not retransmissions should be sent with CSMA. The description appears to suggest sending them without CSMA, but that seems imprudent. Also ambiguous if a retransmission should occur due to a complete CSMA failure. The description leans towards not re-attempting transmission in this case. This seems somewhat reasonable, but should be clarified.