MAC Clarifications & Questions for IEEE 802.15.4b Task Group

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, Richard Kelsey, Ed Hill] 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. Robert Poor, Lee Taylor, Ember

2. MAC Clarifications and Questions Robert Poor <robert.poor@ember.com> Lee Taylor <lee.taylor@ember.com> Richard Kelsey <richard.kelsey@ember.com>Ed Hill <ed.hill@ember.com>Zachary Smith <zachary.smith@ember.com> Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

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? Robert Poor, Lee Taylor, Ember

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? Robert Poor, Lee Taylor, Ember

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. Robert Poor, Lee Taylor, Ember

11. Section 7.5.1.3: CSMA exceeding CAP • In Section 7.5.1.3 describing the CSMA algorithm, it says that for a slotted CSMA-CA system the MAC shall ensure that after the random backoff the entire transaction can be transmitted by the end of the CAP. If the backoff fits within the current CAP the MAC sublayer should "apply its backoff delay" and then evaluate whether or not it can complete the transmission within the current CAP. If not, it should wait until the start of the next CAP and then 'repeat the evaluation'. From context it appears that 'the evaluation' is the check to see if the message will fit within the new CAP. • This procedure has the effect of synchronizing the CCA checks of all messages whose backoff falls too late in the CAP for the message to be transmitted. In effect the backoff periods at the end of the CAP get collapsed into the single backoff period at the beginning of the next CAP. The number of collapsed periods depends on the length of the messages being sent. • One solution would be not to count backoff periods in which the current message cannot be transmitted towards the backoff delay. In other words, a delay of N periods means to wait N periods during which the MAC could have started transmission. Periods where it could not have started, because of insufficient time left in the current CAP, would not count. Robert Poor, Lee Taylor, Ember

12. Synchronous ACKs • It may be desirable to maintain synchronization while switching between transmitting and receiving. In situations of weak links, many messages are dropped due to failure to synchronize. It might help if the 15.4 fast ack could be sent without having to resynchronize at the bit level. Robert Poor, Lee Taylor, Ember

13. PAN ID Conflict If you associate with someone who isn't the PAN coordinator and then hear a beacon from the PAN coordinator, should that count as a PAN ID conflict? • *7.5.2.5 Device discovery* Page 148 line 50: An FFD, that is not the PAN coordinator, shall only begin transmitting beacon frames when it has successfully associated with a PAN. The transmission of beacon frames by the device is initiated through the use of the MLME-START.request primitive with the PANCoordinator parameter set to FALSE. On receipt of this primitive, the MLME shall begin transmitting beacons using the identifier of the PAN with which the device has associated, macPANId, and its short address, macShortAddress. If a device associates with a coordinator that is not the PAN coordinator, then the macPANId will be the same as that of the PAN coordinator, but the macCoordShortAddress will be different. • *7.5.2.2 PAN Identifier conflict resolution* Page 147 line 45: A device shall conclude that a PAN identifier conflict is present if the following applies: - A beacon frame is received by the device with the PAN coordinator subfield set to 1, the PAN identifier equal to macPANId and an address which is not equal to macCoordShortAddress. If the device then hears a beacon from the PAN coordinator, this would count as a PAN ID conflict. This seems wrong. Robert Poor, Lee Taylor, Ember

14. Broadcasting to sleeping devices • See clause 7.2.2.1.6 "Pending address specification field" and clause 7.2.2.1.7 "Address list field" in the MAC spec. They discuss how associated devices are informed that there is data for them at the coordinator. Clause 7.2.2.1.7 specifically disallows the use of the broadcast address. In a network where end devices are likely to be asleep much of the time and where, in the beacon-enabled case, even routers may sleep during the inactive period of their parent's superframe, how can broadcasts work at all? • For example, let's say a router with sleeping children gets a broadcast packet. If it just relays the packet after a little jitter then there is an excellent chance that none of its children will ever hear it. But what choice does it have? This is exactly what indirect transmission in 15.4 was designed for but... as detailed above, the indirect transmission mechanism doesn't support broadcast. Robert Poor, Lee Taylor, Ember

15. Extracting Pending Data from a Coordinator • 7.5.6.3 Extracting Pending Data from a Coordinator • Once successfully polled, the pending data frame can be transmitted to the node in two ways: 1) without CSMA if certain timing conditions can be met, or 2) with CSMA if they cannot be. However, the requesting device only waits for aMaxFrameResponseTime (1180) symbols before giving up and deciding there is no pending data. 1180 symbols is 59 backoff slots, which can be exceeded by the CSMA algorithm on a busy network. At worst could be exceeded with 3 CSMA failures, but on average would take 5 CSMA failures, which is more than the default number of attempts. (Note that this has been observed happening.) Presumably the spec could also state that in the case of using CSMA the transmission is given higher priority than anything else currently sitting in the transmit queue. Probably even overtaking a transmission currently in the process of CSMA. Robert Poor, Lee Taylor, Ember

16. Extracting pending data • 7.5.6.3 Extracting pending data/7.2.2.3 Ack frame format • The spec is ambiguous about whether the frame pending subfield should be set in response only do data request messages, or if it should be set whenever any messages from a device the coordinator has pending data need an ack. 7.2.2.3 states it should be set according to whether there is "more" data pending for the recipient. The use of "more" is unclear.. perhaps the word should not be there? 7.5.6.3 is the only other section which mentions the use of the frame pending subfield, and clearly lays out how it is supposed to be set in response to the data request, but does not help to clarify if it should be set in response to other messages as well. It is also not clear if the frame pending subfield should be set when a message is sent to a device normally, but there is also something waiting to be transmitted indirectly for that same device. It was probably not envisioned that this should occur, but nothing in 15.4 itself prevents this situation from arising. Robert Poor, Lee Taylor, Ember

17. Active Scan • 7.5.2.1.2 Active Scan • A 15.4 star network is only likely to get a single response to an active scan on a given channel (or at least a very small number of responses if there are a few neighboring star networks). Zigbee relies on actives scans for building up networks where there may be a large number of responders. In this case, when on a non-beacon enabled network the scan performs very poorly. In this situation, all the devices receive the beacon request message at the same time, in effect synchronizing them. The beacon that is sent in response is sent with CSMA, but the initial backoff allows for only one of 8 possible choices of when to send the beacon. Since the responders are synchronized by the reception of the original message CSMA doesn't work well. With only 8 choices, it is quite likely that many of them will choice the same initial backoff, see that CCA is clear, and then begin transmitting at the same time. Additional variability in the timing of the response is required. Robert Poor, Lee Taylor, Ember