Context Navigation

tutorial_token_mac

Timestamp:: Jul 13, 2015, 10:01:39 PM (9 years ago)
Author:: murphpo
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

802.11/wlan_exp/app_notes/tutorial_token_mac

-                      v13
+                      v14
 [[TracNav(802.11/TOC)]]
 = Tutorial: Building a Completely Custom MAC =
+= Tutorial: Building a Custom MAC  with the 802.11 Reference Design =
 A major feature of [wiki:802.11 the 802.11 Reference Design] is its compliance to the 802.11 standard to enable interaction with commercial Wi-Fi devices. This is the design in its "reference" state -- a known quantity that is ''intended'' to be modified to suit the needs of research applications. In our [wiki:802.11/wlan_exp/app_notes other app notes], we made small modifications to the design and characterized how those design changes manifested using the [wiki:802.11/wlan_exp WLAN Experiments Framework]. Ultimately, however, those design changes were small and the design you ended up with was a mildly tweaked 802.11 implementation.
+A major feature of [wiki:802.11 the 802.11 Reference Design] is its compliance to the 802.11 standard to enable interaction with commercial Wi-Fi devices. This is the design in its "reference" state -- a known quantity that is ''intended'' to be modified to suit the needs of research applications. In our [wiki:802.11/wlan_exp/app_notes other app notes], we made small modifications to the design and characterized how those design changes manifested using the [wiki:802.11/wlan_exp WLAN Experiments Framework]. Ultimately, however, those design changes were small and the resulting design differed from the 802.11 standard only slightly.
 This application note is fundamentally different -- we will build a completely non-standard MAC from scratch and use the [wiki:802.11/wlan_exp WLAN Experiments Framework] to characterize our novel design. The intent of this application note is to act as a tutorial. It is a step-by-step example of how to build something that really does not even resemble the standard 802.11 MAC. In fact, the MAC we will build in this tutorial is really the philosophical opposite to the 802.11 Distributed Coordination Function (DCF). The DCF is the classic example of a random access MAC. In this tutorial, we will build a simple scheduled access MAC that we call "TokenMAC."
+This application note is different -- we will build a non-standard MAC from scratch and use the [wiki:802.11/wlan_exp WLAN Experiments Framework] to characterize our novel design. This application note is structured as a tutorial, describing step-by-step how to build and evaluate a custom MAC protocol. The MAC presented here is very different from the standard 802.11 Distributed Coordination Function (DCF). The standard DCF is a classic example of a random access MAC. In this tutorial, we will build the opposite- a simple, scheduled-access, token-passing MAC we call "TokenMAC".
 == Overview of TokenMAC ==
 The entire purpose of a MAC is to figure out a way that a shared wireless medium can be split up amount multiple competing devices. The standard 802.11 DCF employs randomness to achieve this goal and avoid deadlocks where multiple nodes continually collide when accessing the medium. In this tutorial, we will implement a completely different kind of MAC based on [https://en.wikipedia.org/wiki/Token_ring the token ring]. This MAC does not use randomness to avoid collisions but rather explicitly allows only a single transmitter at a time by passing around a token that authorizes transmissions. This is a form a scheduled access MAC (as opposed to a random access MAC).
+The purpose of a MAC protocol is to share the wireless medium among competing devices. The standard 802.11 DCF employs carrier sensing and random transmission timing to coordinate medium access without a central controller. In this tutorial, we will implement a different kind of MAC protocol, one based on the idea of a [https://en.wikipedia.org/wiki/Token_ring token ring]. Our custom MAC uses a centrally controlled token passing scheme to assign transmission slots deterministically. This MAC avoids collisions by explicitly reserving the medium for each node in the network. One node in the network (the AP in our case) is responsible for defining the schedule and passing the token.
 ||  [[Image(wiki:802.11/wlan_exp/app_notes/tutorial_token_mac/figs:token_overview.png, width=900)]]  ||
 ||  ''TokenMAC avoids contention not through randomness, but rather through explicit token passing from a managing Access Point (AP).'''  ||
+||  ''TokenMAC avoids contention through explicit token passing from a managing Access Point (AP).'''  ||
+To create TokenMAC, we will need to alter pieces of the underlying reference design. This application note is organized into the following sections:
+Implementing TokenMAC requires modifications to the MAC code in the 802.11 Reference Design. This tutorial does not require any changes to the Reference Design hardware.
+ * '''[wiki:./CPU_HIGH Alterations to CPU_HIGH]''' -- In this section, we will describe and discuss the changes needed to the high-level MAC code to realize the design. Specifically, we will modify the AP codebase to allow it to determine which node in the network should have the token and for how long it should have it.
+ * '''[wiki:./CPU_LOW Alterations to CPU_LOW]''' -- In this section, we will describe and sicuss the changes needed to the low-level MAC code to realize the design. Here, we will not start off with the DCF code since the vast majority of that DCF behavior is irrelevant to TokenMAC. Instead, we will use the very simple [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_low_nomac NoMAC] project as a starting point. Unaltered, this project acts as a straight passthrough connection between the high-level MAC and the PHY.
+ * '''[wiki:./characterization Characterizing the Design]''' -- Once the design is complete, we will use the [wiki:802.11/wlan_exp WLAN Experiments Framework] to characterize the design and analyze its strengths and its weaknesses.
+ * '''[wiki:./extensions Extensions]''' -- Having established the design's weaknesses in the previous characterization section, we will propose and construct extensions to TokenMAC to strengthen its weaknesses. The intent of this section is to demonstrate how to "close the loop" between design, experimentation, and then re-design based on what was learned during the experimental phase.
+This application note is organized as follows:
+ * '''[wiki:./CPU_HIGH Changes to CPU_HIGH Code]''' -- Describes the changes required in the high-level MAC code. TokenMAC requires modifications to the AP application to implement the MAC's central controller.
+ * '''[wiki:./CPU_LOW Changes to CPU_LOW Code]''' -- Describes the changes required to the low-level MAC code. The low-level TokenMAC implementation is based on [browser:ReferenceDesigns/w3_802.11/c/wlan_mac_low_nomac NoMAC], which provides a "clean slate" on which to build the custom MAC protocol.
+ * '''[wiki:./characterization Characterizing the Design]''' -- Once TokenMAC is operational, we will use the [wiki:802.11/wlan_exp WLAN Experiments Framework] to characterize the design and analyze its strengths and its weaknesses.
+ * '''[wiki:./extensions Extensions]''' -- Having identified a few of TokenMAC's key weaknesses in the previous section, we will describe and construct enhancements to the basic TokenMAC protocol. The intent of this section is to demonstrate how to "close the loop" between protocol design, experiment design, characterization, and re-design based on empirical results.