Log items

1. 16(201) Need to stop any timer(s) running when MLME_RESET_request. Done 4/22/03 Added new procedure to reset all timers. The procedure does not check if the timer is running before resetting it.
2. 31(201) Might want to add Za to the possible outcome state after a SCAN. Done 4/22/03
3. 45(201) If no orphan is found (i.e. coordinator realignment command), then what should the end state be? Done 4/22/03 See 7.5.4.3 [Wait for further instructions from higher layer]
4. 50(201) Only state should be A, since if a device receives a coordination realignment command, then it is considered to be associated (A). Done 4/22/03
• i. What happens if it is a broadcast coordination realignment command?
• ii. What about going to Yp (meaning not associated)?
5. 52(201) Need to put all timers on hold for beaconing period. There are eleven (11) timers currently in the SDLs.
• * T_AckWait is not considered, since it is only running to receive the acknowledgement following the sent data or MAC command and would not be running unless there was time before the next beacon.
• * T_backoff is not considered, since it is already accounting for the beacon period.
• * T_beacon is not considered, since it is the timer that causes this event/situation.
• * T_btp is not considered, since it is not running if T_beacon is running. That is either the device is sending beacons or it is receiving beacons.
• * T_defertime is not considered, since it is already accounting for the beacon period.
• * T_GTSDescPersistenceTime is not considered, since it is counting the beacon periods, so it shall not be reset (stopped).
• * T_MaxFrameResponseTime needs to be paused, since it is only active during the CAP.
• * T_ResponseWaitTime is not considered, since it is the time permitted for another device to response.
• * T_RxOnTime is not considered, since it is already accounting for the beacon period.
• * T_scan_duration is not considered, since it is only operating during scanning states and during these states the sending of beacons is stopped.
• * T_superframe is not considered, since it is either expiring before T_beacon or is equal to T_beacon.
6. 68(201)/ 68(199) Add boolean to accommodate unknown variable. Done 4/23/03 fast enough
7. 71(201)/ 71(199) Add boolean to accommodate uncalculated duration. Done 4/23/03 shortenough
8. 71(201) If a device receives a beacon request, it must send a beacon, not a beacon request. Done 4/22/03
9. 74(180) Now 75(201) Perhaps add a state Zp1 to consume PLME_SET_request's matching confirm before proceeding to B. Done 4/23/03
10. 75(201) Need to add the setting of MacPIB!macPANId with Coordinator. Done 4/23/03 Now part of Zp1 state.
11. 78(201) Need to consume PLME_SET_TRX_STATE_confirm. Done 4/22/03
12. 79(201) If while tracking the beacon a failure occurs, what state is the appropriate state for the ending state? Done 4/22/03 See 7.5.4.1 page 152 D18
13. 85(201) If while tracking the beacon, a Pid conflict is discovered, will an RFD have storage for the MAC command if it is currently sending or will it interrupt the current data, or will it do something else?
14. 130(201) If a device fails to send something, then it needs to return to the previous state prior to the failure. Done 4/22/03 The following pages lead to state B:
• o 54(199) ready_beacon2
• o 71(199) Za
• o 75(199) Zp
• o 85(199) TrackBeacon
• o 88(199) TrackBeacon
• o 93(199) A (data) [MCPS_DATA_request]
• o 105(199) A (datarequest) [PD_data_indication]
• o 116(199) A [MLME_GTS_request]
• o 121(199) A [MLME_POLL request]
• o 135(199) F
• o 147(199)G
• o 153(199) wait_response [T_responseWaitTime]
• o 173(199) A [MLME_disassociate]
• o 184(199) A [MLME_Orphan_response]
15. 138(201) While waiting for an Acknowledgement, will a device accept other frames? Done 4/22/03 No, T_ackwait is only long enough to receive the Acknowledgement following the sent data or MAC command. Therefore it does not have time to receive something else.
• i. However, will this cause a priority clash if it is still waiting to retransmit when a beacon is received which causes a data_request or pid conflict?
16. 142(201) Change behavior of GTS request, to account for change in procedure from D17. Done 4/22/03
17. 143(201) End state for NOT PAN coordinator should be Zp, W, and Za. Done 4/22/03
18. 145(201) Check FramePending Field Flags to determine whether another data_request MAC command is needed. Done 4/24/03
19. 146(201) End state, H = await_frame. Done 4/22/03
20. 145(201) & 146(201) F_poll & F_datarequest need to determine the difference and similarities to see if these can be combined. Done 4/24/03
21. 148(201) Behavior of H state may match the behavior of await_frame state. Done 4/22/03 Delete state since it does match await_frame state.
22. 149(201) Behavior of H state may match the behavior of await_frame state. Done 4/22/03 Delete state since it does match await_frame state.
23. 150(201) Behavior of H state may match the behavior of await_frame state. Done 4/22/03 Delete state since it does match await_frame state.
24. 151(201) No way to enter send_ack state Done 4/22/03 Delete state.
25. 152(201) No way to enter send_ack state Done 4/22/03 Delete state.
26. 153(201) No way to enter send_ack state Done 4/22/03 Delete state.
27. 154(201) Add tx0 = at least 1 for acknowledgement requested. Done 6/5/03
28. 156(201) Need to stop timer, T_maxFrameResponseTime when data or MAC command is received. Done 4/22/03
29. 156(201) Need to check for more pending data. Done 4/24/03
30. 156(201) Need to process the received MAC command, not just send MLME_POLL_confirm. Done 4/24/03
31. 163(201) Other end states when leaving ED scan. Done 4/22/03
32. 179(201) Add MLME_COMM_STATUS_indication with transaction overflow. Done 4/23/03
33. 179(201) Add test parameters. 4/23/03 It was determined that there is no need to check the parameters of the MLME_ASSOCIATE_Response or MLME_ORPHAN_response, since there is no values to compare the parameters with to determine whether they are invalid.
34. 184(201) Add test parameters. 4/23/03 It was determined that there is no need to check the parameters of the MLME_ASSOCIATE_Response or MLME_ORPHAN_response, since there is no values to compare the parameters with to determine whether they are invalid.
35. 189(201) May combine MLME_SCAN_request with 18(201) after updating return states for all branches. Done 4/24/03
36. Prepare for GTSs inclusion. Done 7/1/03
37. While in state F, is the RX_ON? Done 4/22/03 Yes it is on, but only long enough for the Acknoledgement frame.
38. Added NumAssoc to count the number of associated devices so that it is 141(199) increased when ack from associate response and decreased when disconnect received or ack or pending. Added to DCL and mac_init.
39. Does a polled data of zero length get acknowledged. Done 4/22/03 No See 7.5.6.3 page 156 D18
40. Duplicate detection. Done 4/22/03 No longer present in text.
41. Must a FFD associate when it receives a MLME_START_request? Done 4/22/03 No, it must already be associated Table 58, page 99 D18
42. Add PD_DATA_indication to state W mark as most likely impossible
43. Add PD_DATA_indication to state C mark as BUSY. Done.
44. Clear message (i.e., set to no_message) when transaction is concluded. Done. 6/5/03
45. What source addressing mode and address to use for the MLME_COMM_STATUS_indication in response to the MLME_ASSOCIATE_response, were determined to be the values that would have been used in the association response command. 4/23/03
46. Select response 2(2) T_GTSDescPersistenceTime is not set properly and do not think it should be. Done. 6/11/03
47. 100(201)/106(202) Needs to be updated with the two Booleans for sending Acknowledgement and checking for pending data. Done 4/25/03
48. Determine if PD_data_indication in state A can be combined with PD_data_indication in state await_frame
49. 19(201) add test for iMaxChannel & Invalid parameters & add post_scan Done 4/24/03
50. 20(201) add test for iMaxChannel & Invalid parameters & add post_scan Done 4/24/03
51. 21(201) add test for iMaxChannel & Invalid parameters & add post_scan Done 4/24/03
52. 22(201) add test for iMaxChannel & Invalid parameters & add post_scan Done 4/24/03
53. 162(200) unscanned list cannot be < zero
54. 163(200) need to reset PANId (replace with post_scan) 4/24/03
55. 163(200) need to consume PLME_SET_TRX_STATE_confirm in ED before proceeding to end state. Done 4/24/03
56. 113(204) update channel_list to be power of 2, not multiple of 2. Done
57. 25(202) might be able to remove, since other states consume it.
58. 52(202) send ack in response to coordinator_realignment command Done 4/25/03
59. Might be able to combine Za (67-77) with A (102-122)
60. Determine whether A and Await_frame can be combined with the Timer as the difference condition.
61. 161(205) need to process command received. Done
62. 162(205) need to process data and send acknowledgement. Done
63. Try variable for difference in Unslotted states instead of new states
64. Need to consume PLME_SET_TRX_STATE_confirm in A as a result of 53(206). Done. 6/5/03
65. Phylayer 19(24) add condition if while in RX_ON and T_ed or T_cca running then return BUSY condition. Done 4/25/03
66. Must get Trackbeacon, F, wait_reswponse, and await_frame states to accept beacon frame for pending messages. Done. Solution was to transition to the Trackbeacon state to receive the Beacon frame and then return to the prior state.
67. Some how keep the beacon from interrupting psdu messages in progress of transmissions. Done. Changed the create_beacon to use bea_psdu instead of psdu. Did the same for the acknowledgement (ack_psdu).
68. Association response psdu still in pending list, but not recognized for ack generation or beacon generation. Done. 6/10/03
69. 164(206) select response end state not correct for a failed association request. Done
70. 18(24) Physical multiply by 8 the symbol duration to achieve correct value. Done.
71. Need to update current_channel whenever MLME_SYNC_request is successfully used. Done 5/9/03
72. When T_btp or T_beacon are updated make sure that BeaconRxTime and macBeaconTxTime are also updated. BeaconRxTime really gets updated with the correct value when a Beacon frame is received. Done 5/9/03
73. Must update CSMA/CA boundary conditions to include CAP (i.e. GTS) not just Superframe. Done
74. 91(210), 125(210), and 1(1) parse_coord Update MacPIB!macAckWait Duration according to current_channel. Done 5/9/03
75. 67(207) Add MLME_START_confirm to final step before entering Za. Done 5/9/03
76. Clear psdu and length after sending beacon request command. To ensure that correct psdu and length are saved. Done. 6/5/03 Did not clear psdu and length, but rather used difference variables for beacon and acknowledgements, so that currently being processed psdu are not over written.
77. Might shut off TRX_OFF after finding Beacon, but need to make sure RX_ON is not disabled when it should not be
78. 83(21) Add decision for if current_channel equals clc, if so do not waste time setting it again. Done 5/7/03
79. Calculate_remaining 1(1) add additional test for device type BeaconRxTime, not just macBeaconTxTime Done 5/9/03
80. Add T_btp to state B, since State B is now considered a stable state when crossing beacon/superframe boundaries. Done.
81. Beacon_enabled_pan is never set because condition is not known. Done 5/7/03. (replaced it with macBeaconOrder check)
82. Changed create_beacon so that it does not replace initial psdu and length. Done 5/8/03
83. Add GTS s_length := s_length + 1 to indicate minimum inclusion of GTS field. Done 5/8/03
84. Update transition fro X_as4 to Ya. Done 5/8/03
85. Update transition fro Ya to Za. Done 5/8/03
86. Update superframe order in the received beacon during tracking so that it can be used to locating boundary. Done 5/8/03
87. Locating boundary difference with BeaconRxTime and macBeaconTxTime. Done 5/8/03
88. Change symbolduration to 1 (meaning one symbol is the unit of time) in both mac_init and init_Phy_variables. Done 5/8/03
89. Association_response change to p_psdu Done. 6/5/03
90. Change store pending to include parameter (e.g. psdu) Done. 6/4/03
91. Added pow procedure and used it to update the following: set_superframe_interval 1(1), set_beacon_track_period 1(1), set_beacon_scan_interval 1(1), set_beacon_interval 1(1), select_channel 2(2), calaculate_duration 1(1). Done 4/29/03
92. Could also update is_it_supported 1(1) [need to export] and update_unscanned 1(1)
93. set_beacon_track_period 1(1) and set_beacon_search_period 1(1) are the same should delete one. Done. 5/20/03 Deleted set_beacon_track_period
94. Reconcile the sending of the three (3) primitives for the sending of the ack in any state that does this. PLME_SET_TRX_STATE_request(TX_ON), PD_DATA_request(Ack), and PLME_SET_TRX_STATE_request(RX_ON) and their "confirms". Done. 6/6/03 Created multiple states to interrupt normal state for sending the acknowledgement frame and then return to process received frame.
95. Consider Coordinator Realignment command received with a change in BO, what effects on Timers?
96. Consider change in CAP size, what effects on Timers?
97. Consider multiple beaconing devices competing with PAN coordinator.
98. Consider Zp and Ya equal states (i.e. scanned) change lettering to make them look similar (i.e. change Zp to Yp), Thus making the "Y" state completed scans, but neither associated nor beaconing.
99. No need to add CW into calculation for cancompleteTX, since it is a fixed value of 2. Done. 5/12/03
100. Page 158(217) F_poll need to complete (verify r_fc!fpf=0 true leg)
101. 95(276) May want to add more states.
102. 104 (276) T_btp is not SET upon leaving Tracking_Beacon due to finding a PAN ID conflict.
103. 186 (276) is PLME_SET_TRX_STATE_request properly consumed in the returned to state?
104. 227 (276) investigate Yp "failed to associate"
105. 261 (376) investigate adding pending_reset.