User:Ofriedri

BitRateSelection: Integration into JiST/SWANS

Motivation of work

Bit rate selection in Wireless Network is still a relatively new research topic. The inherent support of data transmission at different bitrates within the 802.11 MAC layer motivates exploitation of this feature. Previous work has come up with several interesting bit-rate selection algorithms. However, implementation of these inside widely-used network simulators (such as ns-2 and JiST/SWANS) has been sparse.

The current project is dedicated to add support of several bitrates into the JiST/SWANS simulation environment and implementing on top of it several bit-rate selection algorithms. There are three steps in this project, which are listed chronologically:

1. Extending the MAC (a) and Radio (b) layers to support choice of different physical layer (PHY) models (OFDM, DSSS/CCK, ERP-OFDM, ERP-DSSS/CCK)
2. Implementation of popular/promising bit-rate selection algorithms on top of the modified Radio and MAC layers
3. Possible development of a special bit-rate selection algorithm for opportunistic routing

1. Extending the MAC and Radio layers to support multiple 802.11 MAC standards

SWANS MAC layer now supports:

• 802.11 (but only DSSS PHY, since FHSS PHY is hardly used anymore)
• 802.11b (with DSSS and CCK PHYs; PBCC PHY is not yet implemented since it's not obligatory in the 802.11b standard paper)
• 802.11a (OFDM PHY at 5 GHz)
• 802.11g (ERP-OFDM, ERP-DSSS and ERP-CCK; ERP-PBCC and DSSS-OFDM are not yet supported since not obligatory)

Nevertheless, extending the basis of supported MAC/PHY layers is now only a matter of adding a few more constants and the appropriate branches in decision trees, where the PHY and/or MAC layer influence the result. Once the implementation of the above-mentioned layers is flawless, extensions are easily adopted.

1a. Extending the MAC layer to support multiple PHYs

Source code base: svn://brn-svn/brn/simulation/NetCodExOR (svn co ~)

Considerations:

• move constants to jist.swans.Constants.java to reduce code length and increase readibility; would also be more coherent with JiST/SWANS structure
• bitrate annotation at message level: has to be reconsidered when implementing the first bit-rate selection algorithm:
  • Is a service based interface ( getBitrate(); and  setBitrate(int bitrate);) not enough?
• Using  wavelength and  bandwidth from  RadioInfoShared doesn't allow stations to support e.g. 802.11a and 802.11g at the same time, but new wireless cards do, i.e. Intel Wireless 2915abg . We need a solution here. Maybe:
  • support a set of MAC layers, that can be provided at simulation start --> drawback: change of  class RadioInfoShared

Description	concerned file(s)	changed/added code
introducing new constants for: bandwidth	jist.swans.Constants	in class Constants: public static final int BANDWIDTH_1MBit = (int) 1e6; // 1Mb/s public static final int BANDWIDTH_2MBit = (int) 2e6; // 2Mb/s public static final int BANDWIDTH_5_5MBit = (int) 5.5e6;// 5.5Mb/s public static final int BANDWIDTH_6MBit = (int) 6e6; // 6Mb/s public static final int BANDWIDTH_9MBit = (int) 9e6; // 9Mb/s public static final int BANDWIDTH_11MBit = (int) 11e6; // 11Mb/s public static final int BANDWIDTH_12MBit = (int) 12e6; // 12Mb/s public static final int BANDWIDTH_18MBit = (int) 18e6; // 18Mb/s public static final int BANDWIDTH_22MBit = (int) 22e6; // 22Mb/s public static final int BANDWIDTH_24MBit = (int) 24e6; // 24Mb/s public static final int BANDWIDTH_33MBit = (int) 33e6; // 33Mb/s public static final int BANDWIDTH_36MBit = (int) 36e6; // 36Mb/s public static final int BANDWIDTH_48MBit = (int) 48e6; // 48Mb/s public static final int BANDWIDTH_54MBit = (int) 54e6; // 54Mb/s
adapt MacMcExOrMessage to include information about the bitrate at which it is supposed to be sent	brn.swans.mac.MacMcExORMessage.java	in class MacMcExORMessage: /** Bitrate at which to transmit this message */ protected int bitrate; /** @return The bitrate at which to transmit this message */ public int getBitrate() { return bitrate; }; in class MacMcExORMessage.Ack: public Ack( /* previously existent parameters */ , int bitrate) { ... // same code as in previously existent constructor this.bitrate = bitrate; // added this line } in class MacMcExORMessage.Data: public Data( /* previously existent parameters */ , int bitrate) { ... // same code as in previously existent constructor this.bitrate = bitrate; // added this line } Also adapted the  equals methods of all three classes to reflect the presence of the new member variable  bitrate.
Adapt the MAC layer: add necessary constants for all PHY models to be supported add necessary member variables to the Configuration class change/add Constructors	brn.swans.mac.MacMcExOR.java	in class MacMcExOr: // TODO

1b. Adapting the Radio layer

TODO:

• adapt the Radio layer to support different sensitivity values (dB) according to the PHY layer
• Try to keep logic in MAC layer so that there will be a central management of the MAC/PHY layer and the corresponding values. Sensitivity values in the Radio layer are all dependent on the MAC/PHY layer chosen, so it makes sense to implement that kind of logic.
• In the Radio layer there could be methods  setSensitivityXY(int sensitivityValue); and  getSensitivityXY(); to realize this approach.

2. Implementation of bit-rate selection algorithms

Candidates for implementation are:

1. AARF - Adaptive Auto Rate Fallback ()
2. SampleRate (PDF)
3. RBAR - Receiver-Based Auto-Rate (PDF)

3. Bit-rate selection in combination with opportunistic routing

• ExOR
• McExOR

Useful links

1. WikiHelp