| | 1 | WinlabMadwifi -> Driver Wish List |
| | 2 | |
| | 3 | = MAC experiments envisioned = |
| | 4 | The testbed is designed to support an open API for MAC protocol design. While the ultimate goal is to provide maximum flexibility for end-user’s arbitrary MAC algorithm, we have a near-term goal to implement and verify a series of cutting-edge MAC protocols derived from IEEE 802.11 MAC, but has very important variations to improve the performance of wireless ad-hoc networks. Following MAC experiments are going to |
| | 5 | be verified in Orbit testbed and all of them have some modifications of basic CSMA/CA mechanism. |
| | 6 | |
| | 7 | * '''DCMA (Data-driven Cut-through Multiple Access Protocol''' |
| | 8 | |
| | 9 | This new MAC protocol uses a new combo ACK/RTS frame to resolve the contentions within the same multi-hop flow. Thus, the RTS and ACK frame formats needs to be changed. Correspondingly, it is necessary to implement a new control frame’s handling routine for 802.11 chip’s firmware or driver. |
| | 10 | |
| | 11 | * '''MACA-P protocol''' |
| | 12 | |
| | 13 | This protocol uses an innovative way to establish parallel transmissions. Basically, the nodes which exchange an RTS/CTS reservation do not transmit the DATA frame immediately, but waiting for a time gap to let multiple transmissions happen in parallel. Thus, both the format and timing relationship between the control frames and DATA frames needs to be adjusted. |
| | 14 | |
| | 15 | * '''D-LSMA protocol''' |
| | 16 | |
| | 17 | Distributed Link Scheduling Multiple Access is designed to facilitate real-time multi-hop flows. Using ns-2 simulation, it has been seen to |
| | 18 | give ~30% throughput improvement for wireless mesh network. The protocol suppresses the ACK frames and extends RTS/CTS format for support periodic |
| | 19 | traffic patterns. Thus, to realize this protocol, the ACK has to be disabled and the frame format needs to be changed. |
| | 20 | |
| | 21 | = Desired Features = |
| | 22 | |
| | 23 | The features requested are divided into four groups |
| | 24 | |
| | 25 | == Basic MAC level changes == |
| | 26 | |
| | 27 | The following features are desirable |
| | 28 | * '''Can the value of Carrier Sensing threshold of CSMA be changed or disabled? ''' |
| | 29 | |
| | 30 | By doing that we could calibrate and adjust the interference range of a node. And this |
| | 31 | interference range is a very dedicate and key parameter for verify a series of MAC |
| | 32 | protocols physically. |
| | 33 | * '''Could the timing relationship of the control frames be adjusted? ''' |
| | 34 | |
| | 35 | We know the SIFS, DIFS, EIFS are inter-frame timings used in various version of 802.11 |
| | 36 | standards. And we think it might be a flexible parameter to be set conveniently. |
| | 37 | But we need some instruction and documentation to do this. |
| | 38 | |
| | 39 | * '''Can we select a Backoff number (of slots) instead of a random-selected number between CWmin and CWmax in addition to change the values of CWmin and CWmax and the time duration of the slot? ''' |
| | 40 | |
| | 41 | We mean if a more generalized algorithm can be implemented to replace that random-number generation part or not |
| | 42 | |
| | 43 | * '''Can we obtain bit error statistics of CRC function for every received MAC frame (MPDU)? ''' |
| | 44 | |
| | 45 | This is used for techniques related to channel estimation. |
| | 46 | |
| | 47 | * '''Can the ACK frames for unicast communication be suppressed? ''' |
| | 48 | |
| | 49 | In other words,can MAC chip just act like a simple FIFO sender and receiver without invoke any MAC state-machines |
| | 50 | |
| | 51 | == Modify existing frames or create new frames == |
| | 52 | * '''Does the MAC implementation provide the ability to generate new control frames,in addition to the RTS, CTS and ACK?''' |
| | 53 | * '''Does MAC implementation provide the ability to change format of current control frames?''' |
| | 54 | |
| | 55 | == AP mode of operation == |
| | 56 | Can the STA be used as an AP? i.e is the Master mode available? |
| | 57 | |
| | 58 | == Statistics report from driver == |
| | 59 | In addition to the MAC level support as described above, the following statistics reported |
| | 60 | by the driver would be useful for cross layer adaptation. These parameters are as follows: |
| | 61 | |
| | 62 | ||'''PHY Layer'''|| |
| | 63 | || Link Quality || |
| | 64 | ||Signal level || |
| | 65 | || Noise level || |
| | 66 | || RSSI || |
| | 67 | || Signal to noise ratio (dBm)|| |
| | 68 | || Modulation Scheme (or PHY Rate used)|| |
| | 69 | || '''MAC layer'''|| |
| | 70 | || No. of retries per packet || |
| | 71 | || Number of frames successfully transmitted || |
| | 72 | || Number of buffer overflows (This will give an indication as to whether the packet loss is at the link or due to buffer overflow)|| |
| | 73 | || Current Contention Window size || |
| | 74 | || Current buffer occupancy || |
| | 75 | || Media access delay |
| | 76 | |
| | 77 | Some additional counters that could be useful are |
| | 78 | * !RxOverrun |
| | 79 | * !RxMacCrcErr |
| | 80 | * !RetryLong |
| | 81 | * !RetryShort |
| | 82 | * !MaxRetries |
| | 83 | * !NoAck |
| | 84 | * !NoCts |
| | 85 | * !RxAck |
| | 86 | * !RxCts |
| | 87 | * !TxACK |
| | 88 | * !TxMc |
| | 89 | * !TxBc |
| | 90 | * !TxUcPackets |
| | 91 | * !TxBeacon |
| | 92 | * !RxBeacon |
| | 93 | * !DupFram |
| | 94 | * !HostTxBytes |
| | 95 | * !HostRxBytes |
| | 96 | * !TxRTS |
| | 97 | * !TxCTS |
