239 | | |
240 | | |
| 239 | ---- |
| 240 | |
| 241 | Finally, we need to make a change that is not technically critical to the operation of TokenMAC, but will make our lives much easier when we actually need to use it. One complication that arises from using timestamps to schedule events is that a node is capable of altering its timestamp an redefining when "now" is. This happens explicitly when you use the [https://warpproject.org/docs/mango-wlan-exp/node.html?highlight=time#wlan_exp.node.WlanExpNode.set_time set_time] method of wlan_exp. It also happens implicitly whenever a STA overrides its own timestamp with the timestamp of a received beacon from its AP. Whatever the reason, we should provide a way to tell the CPU_LOW application when the timestamp is about to change and by how much that change will be. We already created the {{{adjust_reservation_ts_callback}}} callback in the first change above. Now we just need to call it. The {{{wlan_mac_low_set_time()}}} in the MAC Low Framework is the only code that changes the underlying timestamp, so it is the best place to calculate the difference between the new timestamp and whatever the old timestamp was. Add the following snippet of code to the very top of {{{wlan_mac_low_set_time()}}} before it has a chance to actually set the new timestamp: |
| 242 | |
| 243 | |
| 244 | {{{ |
| 245 | #!c |
| 246 | |
| 247 | u64 curr_time = get_usec_timestamp(); |
| 248 | if(curr_time > new_time){ |
| 249 | adjust_reservation_ts_callback( -1*(s64)(curr_time - new_time) ); |
| 250 | } else if(new_time > curr_time){ |
| 251 | adjust_reservation_ts_callback( (new_time - curr_time) ); |
| 252 | } |
| 253 | }}} |
| 254 | |
| 255 | Prior to changing the timestamp, we will notify the CPU_LOW project and provide an offset that is approximately equal to how much the timestamp is about to change. |
| 256 | |
| 257 | ---- |
| 258 | |
| 259 | === NoMAC === |
| 260 | |
| 261 | Changes should be made to [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_low_nomac/wlan_mac_nomac.c wlan_mac_nomac.c]. |
| 262 | |
| 263 | NoMAC is intended to be a near "blank slate" to make building totally custom MACs more straightforward. It does not have any of the complexities of the DCF. Transmissions are directly connected to the PHY. There is no carrier sensing, no acknowledgments, no retransmissions, no random backoffs, etc. NoMAC is the perfect place for us to add the low-level behavior of TokenMAC. |
| 264 | |
| 265 | ---- |