User:Ofriedri: Difference between revisions

From
Jump to navigation Jump to search
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
<!--
<!--
code highlighting: &nbsp;<span style="font-family:Courier New; font-weight:bold"></span>
code highlighting: '''<code> </code>'''
-->
-->
== BitRateSelection: Integration into JiST/SWANS ==
== BitRateSelection: Integration into JiST/SWANS ==
Line 14: Line 14:




=== 1. Extending the MAC and Radio layers to support multiple 802.11 MAC standards ===
=== Extending the MAC and Radio layers to support multiple 802.11 MAC standards ===
SWANS MAC layer now supports:
SWANS MAC layer now supports:
*802.11 (but only DSSS PHY, since FHSS PHY is hardly used anymore)
*802.11 (but only DSSS PHY, since FHSS PHY is hardly used anymore)
Line 23: Line 23:
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.
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 ====
==== Extending the MAC layer to support multiple PHYs ====

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


Considerations:
Considerations:
* move constants to jist.swans.Constants.java to reduce code length and increase readibility; would also be more coherent with JiST/SWANS structure
* 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:
* bitrate annotation at message level: has to be reconsidered when implementing the first bit-rate selection algorithm:
** Is a service based interface (&nbsp;<span style="font-family:Courier New; font-weight:bold">getBitrate();<span> and &nbsp;</span style="font-family:Courier New; font-weight:bold">setBitrate(int bitrate);</span>) not enough?
** Is a service based interface ('''<code>getBitrate();</code>''' and '''<code>setBitrate(int bitrate);</code>''') not enough?
* Using &nbsp;<span style="font-family:Courier New; font-weight:bold">wavelength</span> and &nbsp;<span style="font-family:Courier New; font-weight:bold">bandwidth</span> from &nbsp;<span style="font-family:Courier New; font-weight:bold">RadioInfoShared</span> 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:
* Using '''<code>wavelength</code>''' and '''<code>bandwidth</code>''' from '''<code>RadioInfoShared</code>''' 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 &nbsp;<span style="font-family:Courier New; font-weight:bold">class RadioInfoShared</span>
** support a set of MAC layers, that can be provided at simulation start --> drawback: change of '''<code>class RadioInfoShared</code>'''


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



{| border="1" cellspacing="0" cellpadding="5" align="center"
{| border="1" cellspacing="0" cellpadding="5" align="center"
Line 78: Line 80:
-->
-->
in class MacMcExORMessage.Ack:
in class MacMcExORMessage.Ack:
'''public''' Ack( /* previously existent parameters */ , int bitrate) {
'''public''' Ack( ... , int bitrate) {
... // same code as in previously existent constructor
... // same as before
this.bitrate = bitrate; // added this line
this.bitrate = bitrate; // added this line
}
}
Line 92: Line 94:
-->
-->
in class MacMcExORMessage.Data:
in class MacMcExORMessage.Data:
'''public''' Data( /* previously existent parameters */ , int bitrate) {
'''public''' Data( ... , int bitrate) {
... // same code as in previously existent constructor
... // same as before
this.bitrate = bitrate; // added this line
this.bitrate = bitrate; // added this line
}
}
Line 105: Line 107:
}
}
-->
-->
Also adapted the &nbsp;<span style="font-family:Courier New; font-weight:bold">equals</span> methods of all three classes to reflect the presence of the new member variable &nbsp;<span style="font-family:Courier New; font-weight:bold">bitrate</span>.
Also adapted the '''<code>equals</code>''' methods of all three classes to reflect the presence of the new member variable '''<code>bitrate</code>'''.
|-
|-
| Adapt the MAC layer:
| Adapt the MAC layer:
Line 120: Line 122:
|}
|}



==== 1b. Adapting the Radio layer ====

'''TODO:'''
==== Adapting the Radio layer ====
*adapt the Radio layer to support different sensitivity values (dB) according to the PHY 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.
*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 &nbsp;<span style="font-family:Courier New; font-weight:bold">setSensitivityXY(int sensitivityValue);</span> and &nbsp;<span style="font-family:Courier New; font-weight:bold">getSensitivityXY();</span> to realize this approach.
*In the Radio layer there could be methods '''<code>setSensitivityXY(int sensitivityValue);</code>''' and '''<code>getSensitivityXY();</code>''' 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: '''
{| border="1" cellspacing="0" cellpadding="5" align="center"
| 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
|
{|border="0" cellspacing="0" cellpadding="0" align="left" style="width:110px"
| –82dBm (6Mbps)
|-
| –81dBm (9Mbps)
|-
| –79dBm (12Mbps)
|-
| –77dBm (18Mbps)
|-
| –74dBm (24Mbps)
|-
| –70dBm (36Mbps)
|-
| –66dBm (48Mbps)
|-
| –65dBm (54Mbps)
|}
| 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.
|}

<!--
{| border="1" cellspacing="0" cellpadding="5" align="center"
| '''OFDM''' Sensitivity values (802.11a-1999.pdf)
| [[Image:OFDM Sensitivity sm.JPG]]
|}
-->


=== 2. Implementation of bit-rate selection algorithms ===
=== Implementation of bit-rate selection algorithms ===
Candidates for implementation are:
Candidates for implementation are:
# AARF - Adaptive Auto Rate Fallback ()
# AARF - Adaptive Auto Rate Fallback ()
Line 143: Line 242:


# [http://meta.wikimedia.org/wiki/Help:Editing#The_wiki_markup WikiHelp]
# [http://meta.wikimedia.org/wiki/Help:Editing#The_wiki_markup WikiHelp]
# [https://sarwiki.informatik.hu-berlin.de/wiki/index.php?title=User:Ofriedri&action=edit Edit this page]
# [http://de.wikipedia.org/wiki/Dezibel_%28Umrechnungstabellen%29#dBm_ist_ein_Pegel_mit_Leistungsbezug Conversion table dBm <--> mW (Wikipedia)]
# [[Packet transmission time in 802.11]]

Latest revision as of 18:16, 22 February 2007

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


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(); 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


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


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); and getSensitivityXY(); 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
–82dBm (6Mbps)
–81dBm (9Mbps)
–79dBm (12Mbps)
–77dBm (18Mbps)
–74dBm (24Mbps)
–70dBm (36Mbps)
–66dBm (48Mbps)
–65dBm (54Mbps)
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:

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


Bit-rate selection in combination with opportunistic routing

  • ExOR
  • McExOR

Useful links

  1. WikiHelp
  2. Edit this page
  3. Conversion table dBm <--> mW (Wikipedia)
  4. Packet transmission time in 802.11
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=User:Ofriedri&oldid=6797"