Questions

1. If an Acknowledgement is not received prior to the next beacon, will it still wait for the Acknowledgement in the next superframe? No, T_ackwait is only long enough for turnaround time and Ack frame.
2. If MLME_START.request included reset broadcast but a reset must precede it, how can all this be coordinated?
3. Text states that a device should not request association or GTS if that device is not accepting, since this is a upper layer decision it is not represented in the SDLs, except as noted.
4. For the PAN coordinator its MAC Sublayer does not track duplicate associations. Should it?
5. If in Promiscuous mode no acks are sent. Is this correct?
6. For Disassociation the MAC sublayer appears to be able to determine whether a device is associated, however for an orphan notification it does not. Does the MAC sublayer the necessary information or not?
7. MLME_SYNC.request does not contain enough information to track beacon when a device is not yet associated (i.e. a PAN coordinator that is beaconing). So how can a MLME_SYNC.request precede a MLME_ASSOCIATE.request?
8. If a device might not have enough time to determine whether data is pending, how can frame pending field be properly set?
9. Does a device poll over current sending of data?
10. If using the beaconing CSMA/CA, when calculating whether there is enough space available to do two CCAs, send frame, and receive ACK, why isn't the macAckWaitDuration used instead since it is longer (except for long frame with ack and 2.4 GHz? Otherwise time will be running into the next CAP, right?
11. If during Association/Tracking a Pid conflict is found and not yet associated, will the device send a Pid conflict command?
12. A clash of timers exists when tracking beacon for associate response and CCA to send data request and T_responsewait time.
13. Does T_MaxFrameResponseTime expire on its own or does receipt of a Beacon with pending data stop it? That is will the received data be tested to ensure that the pending data matched the reason for the request (i.e. awaiting data or command)?
14. Other things that need to be set are BO and SO unless the MAC sublayer stores Beacon information from the Scans(active and passive). If defaults are used (i.e. 15) then the scanning period is too long. If defaults are used as stated, then there is no beacon.
15. Which has priority between a beacon pending message and the current process?
16. Which has priority between current, pending, or MAC command frame?
17. MacSuperframeOrder and MacBeaconOrder needed by RFD to track beacons, but table 71 page 135 D18 states not needed.
18. D18 page 100 7.1.14.1.3 On receipt set BO & SO, but what happens if there is a failure upon further processing of the primitive? Nothing is stated about unsetting them.
19. Broadcasting of the Coordinator realignment command must occur before the next scheduled beacon, therefore one must assume that the frame is sent immediately, but this may not be timed correctly, since there may not be enough time to transmit it in the CAP.
20. Are associated devices disassociated when existing PAN coordinator information changes? Perhaps all but macPANId changed.
21. Setting of the IntraPAN subfield as stated in 7.2.1.1.5 is impossible and the text in 7.5.6.1conflicts with this text, eventhough the text there allows the bit to be set.