wiki:Internal/WinlabMadwifi/DriverWishList

WinlabMadwifi -> Driver Wish List

MAC experiments envisioned

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 be verified in Orbit testbed and all of them have some modifications of basic CSMA/CA mechanism.

  • DCMA (Data-driven Cut-through Multiple Access Protocol

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.

  • MACA-P protocol

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.

  • D-LSMA protocol

Distributed Link Scheduling Multiple Access is designed to facilitate real-time multi-hop flows. Using ns-2 simulation, it has been seen to give ~30% throughput improvement for wireless mesh network. The protocol suppresses the ACK frames and extends RTS/CTS format for support periodic traffic patterns. Thus, to realize this protocol, the ACK has to be disabled and the frame format needs to be changed.

Desired Features

The features requested are divided into four groups

Basic MAC level changes

The following features are desirable

  • Can the value of Carrier Sensing threshold of CSMA be changed or disabled?

By doing that we could calibrate and adjust the interference range of a node. And this interference range is a very dedicate and key parameter for verify a series of MAC protocols physically.

  • Could the timing relationship of the control frames be adjusted?

We know the SIFS, DIFS, EIFS are inter-frame timings used in various version of 802.11 standards. And we think it might be a flexible parameter to be set conveniently. But we need some instruction and documentation to do this.

  • 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?

We mean if a more generalized algorithm can be implemented to replace that random-number generation part or not

  • Can we obtain bit error statistics of CRC function for every received MAC frame (MPDU)?

This is used for techniques related to channel estimation.

  • Can the ACK frames for unicast communication be suppressed?

In other words,can MAC chip just act like a simple FIFO sender and receiver without invoke any MAC state-machines

Modify existing frames or create new frames

  • Does the MAC implementation provide the ability to generate new control frames,in addition to the RTS, CTS and ACK?
  • Does MAC implementation provide the ability to change format of current control frames?

AP mode of operation

Can the STA be used as an AP? i.e is the Master mode available?

Statistics report from driver

In addition to the MAC level support as described above, the following statistics reported by the driver would be useful for cross layer adaptation. These parameters are as follows:

PHY Layer
Link Quality
Signal level
Noise level
RSSI
Signal to noise ratio (dBm)
Modulation Scheme (or PHY Rate used)
MAC layer
No. of retries per packet
Number of frames successfully transmitted
Number of buffer overflows (This will give an indication as to whether the packet loss is at the link or due to buffer overflow)
Current Contention Window size
Current buffer occupancy
Media access delay

Some additional counters that could be useful are

  • RxOverrun
  • RxMacCrcErr
  • RetryLong
  • RetryShort
  • MaxRetries
  • NoAck
  • NoCts
  • RxAck
  • RxCts
  • TxAck
  • TxMc
  • TxBc
  • TxUcPackets
  • TxBeacon
  • RxBeacon
  • DupFram
  • HostTxBytes
  • HostRxBytes
  • TxRTS
  • TxCTS
Last modified 13 years ago Last modified on 02/28/06 12:44:53