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:
- 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)
- Implementation of popular/promising bit-rate selection algorithms on top of the modified Radio and MAC layers
- Possible development of a special bit-rate selection algorithm for opportunistic routing
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.
Extending the MAC layer to support multiple PHYs
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();andsetBitrate(int bitrate);) not enough?
- Is a service based interface (
- Using
wavelengthandbandwidthfromRadioInfoShareddoesn'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
- support a set of MAC layers, that can be provided at simulation start --> drawback: change of
Source code base: svn://brn-svn/brn/simulation/NetCodExOR (svn co ~)
| 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( ... , int bitrate) {
... // same as before
this.bitrate = bitrate; // added this line
}
in class MacMcExORMessage.Data: public Data( ... , int bitrate) {
... // same as before
this.bitrate = bitrate; // added this line
}
Also adapted the |
Adapt the MAC layer:
|
brn.swans.mac.MacMcExOR.java | in class MacMcExOr:
// TODO |
Adapting the Radio layer
- 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);andgetSensitivityXY();to realize this approach.
The following table tries to give an overview of the sensitivity and threshold values defined in the 802.11 standard papers:
| Standard | ED_THRESHOLD | CS_THRESHOLD | Comment | IEEE 802.11 Reference | ||||||||
| 802.11 | -76dBm | -80dBm | 50mW < TX Power <= 100mW |
15.4.8.1 Receiver minimum input level sensitivity The frame error ratio (FER) shall be less than 8x10–2 at an MPDU length of 1024 bytes for an input level of –80 dBm measured at the antenna connector. This FER shall be specified for 2 Mbit/s DQPSK modulation. The test for the minimum input level sensitivity shall be conducted with the energy detection threshold set <= –80 dBm. 15.4.8.4 CCA The DSSS PHY shall provide the capability to perform CCA according to at least one of the following three methods: — CCA Mode 1: Energy above threshold. CCA shall report a busy medium upon detection of any energy above the ED threshold. — CCA Mode 2: Carrier sense only. CCA shall report a busy medium only upon detection of a DSSS signal. This signal may be above or below the ED threshold. — CCA Mode 3: Carrier sense with energy above threshold. CCA shall report a busy medium upon detection of a DSSS signal with energy above the ED threshold. | ||||||||
| 802.11a | -62dBm |
|
rate dependent |
17.3.10.5 CCA sensitivity The start of a valid OFDM transmission at a receive level equal to or greater than the minimum 6 Mbit/s sensitivity (-82 dBm) shall cause CCA to indicate busy with a probability >90% within 4 μs. If the preamble portion was missed, the receiver shall hold the carrier sense (CS) signal busy for any signal 20 dB above the minimum 6 Mbit/s sensitivity (-62 dBm). | ||||||||
| 802.11b | -73dBm | -76dBm | 50mW < TX Power <= 100mW |
18.4.8.1 Receiver minimum input level sensitivity The frame error ratio (FER) shall be less than 8×10–2 at a PSDU length of 1024 octets for an input level of –76 dBm measured at the antenna connector. This FER shall be specified for 11 Mbit/s CCK modulation. The test for the minimum input level sensitivity shall be conducted with the energy detection threshold set less than or equal to –76 dBm. 18.4.8.4 CCA The CCA shall indicate TRUE if there is no energy detect or carrier sense. The CCA parameters are subject to the following criteria: a) If a valid High Rate signal is detected during its preamble within the CCA assessment window, the energy detection threshold shall be less than or equal to –76 dBm for TX power > 100 mW; –73 dBm for 50 mW < TX power < 100 mW; and –70 dBm for TX power < 50 mW. b) With a valid signal (according to the CCA mode of operation) present at the receiver antenna within 5 μs of the start of a MAC slot boundary, the CCA indicator shall report channel busy before the end of the slot time. This implies that the CCA signal is available as an exposed test point. Refer to Figure 47 of IEEE Std 802.11, 1999 Edition for a slot time boundary definition. c) In the event that a correct PLCP header is received, the High Rate PHY shall hold the CCA signal inactive (channel busy) for the full duration, as indicated by the PLCP LENGTH field. Should a loss of carrier sense occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted PPDU. Upon reception of a correct PLCP header, the timer of CCA Mode 2 shall be overridden by this requirement. | ||||||||
| 802.11g | -76dBm (?) | ??? | rate & PHY dependent |
19.4.6 CCA performance The CCA shall indicate TRUE if there is no CCA "medium busy" indication. The CCA parameters are subject to the following criteria: a) When a valid signal with a signal power of -76 dBm or greater at the receiver antenna connector is present at the start of the PHY slot, the receiver’s CCA indicator shall report the channel busy with probability CCA_Detect_Probabilty within a CCA_Time. CCA_Time is SlotTime - RxTxTurnaroundTime. CCA_Detect_Probabilty is the probability that the CCA does respond correctly to a valid signal. The values for these parameters are found in Table 123E. Note that the CCA Detect Probability and the power level are performance requirements. b) In the event that a correct PLCP header is received, the ERP PHY shall hold the CCA signal inactive (channel busy) for the full duration, as indicated by the PLCP LENGTH field. Should a loss of carrier sense occur in the middle of reception, the CCA shall indicate a busy medium for the intended duration of the transmitted PPDU. 19.5.1 Receiver minimum input level sensitivity The packet error rate (PER) of the ERP-OFDM modes shall be less than 10% at a PSDU length of 1000 bytes for the input levels of Table 91 of 17.3.10. Input levels are specific for each data rate and are measured at the antenna connector. A noise figure (NF) of 10 dB and an implementation loss of 5 dB are assumed. The PER of the ERP-DSSS modes shall be as specified in 18.4.8.1. |
Implementation of bit-rate selection algorithms
Candidates for implementation are:
Bit-rate selection in combination with opportunistic routing
- ExOR
- McExOR