Table Of Contents

Coexistence of IEEE 802.11 and 802.15.4

Goals

Wireless technologies such as IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 (Zigbee) often operate in the same frequency range, which can lead to cross-technology interference (CTI) between the signals of the two protocols, affecting the performance of both. In the case of 802.11 and 802.15.4, both technologies have versions that use the 2.4 GHz Industrial, Scientific, and Medical (ISM) band, which can result in CTI between the two protocols.

INET has support for simulating CTI between any of its wireless protocol models, including 802.11 and 802.15.4. This allows users to examine how the different protocols interact and affect each other’s operation in a simulated environment.

In this showcase, we will demonstrate the coexistence of INET’s 802.11 and 802.15.4 models and examine how they interact with each other. By the end of this showcase, you will understand how these two protocols can coexist in the same frequency range and the impact of CTI on their operation.

INET version: 4.2

Source files location: inet/showcases/wireless/coexistence

The Model

We’ll examine how CTI can be simulated, see if two interfering wireless technology models can cooperate, and if their cooperation is balanced. We’ll run the example simulation with both 802.11 and 802.15.4 models present, and measure their performance. Also, to get a baseline of their performance, we’ll run the simulation with both models, with just one of them present at a time. Then, we can compare the baseline performance of both models to their concurrent performance.

The example simulation features a Wifi (802.11) and a WPAN (802.15.4) network close to each other. All nodes communicate in the 2.4 GHz band. The signals for the two wireless protocols have different center frequencies and bandwidths, but the signal spectra can overlap. In this showcase, we will configure the two networks to actually use overlapping channels. The channel spectra for both technologies are shown on the following image:

For the WPAN, we’ll use INET’s 802.15.4 narrowband version, in which transmissions have a 2450 MHz carrier frequency and a 2.8 MHz bandwidth by default. For the Wifi, we’ll use 802.11g, in which transmissions have a 20 MHz bandwidth. We’ll leave the frequency and bandwidth of 802.15.4 on default, and we’ll use Wifi Channel 9 (center frequency of 2452 MHz) so that the Wifi and WPAN transmission spectra overlap:

In INET, a radio signal, as a physical phenomenon, is represented by the analog model while it is being transmitted, propagated, and received. As the signal center frequencies and bandwidths of the 802.11 and 802.15.4 models are not identical, the dimensional analog model needs to be used, instead of the scalar analog model. The scalar analog model represents signals with a scalar signal power, and a constant center frequency and bandwidth. The scalar model can only handle situations when the spectra of two concurrent signals are identical or don’t overlap at all. When using the dimensional analog model, signal power can change in both time and frequency; more realistic signal shapes can be specified. This model is also able to calculate the interference of signals whose spectra partially overlap.

In order for the signals of Wifi and WPAN to interfere, the two networks have to share a radio medium module instance. The radio medium module keeps track of transmitters, receivers, transmissions and noise on the network, and computes signal and noise power at reception. The radio medium module has several submodules, such as signal propagation, path loss, background noise, and analog signal representation modules. (For more information, read the corresponding section in the INET User’s Guide.)

The standard radio medium module in INET is RadioMedium. Wireless protocols in INET (such as 802.11 or 802.15.4) often have their own radio medium module types (e.g. Ieee80211DimensionalRadioMedium), but these modules are actually RadioMedium, just with different default parameterizations (each parameterized for its typical use case). For example, they might have different defaults for path loss type, background noise power, or analog signal representation type. However, setting these radio medium parameters are not required for the simulation to work. Most of the time, one could just use RadioMedium with its default parameters (with the exception of setting the analog signal representation type to dimensional when simulating CTI).

For our simulation, we’ll use RadioMedium. Since we’ll have two different protocols, the analog model and the background noise of the radio medium and the protocol specific radios need to match (they need to be dimensional). We’ll set just these two parameters, and leave the others on default.

In INET, different types of radio modules (e.g. 802.11 and 802.15.4) can detect each other’s transmissions, but can only receive transmissions of their own type. Transmissions belonging to the other technology appear to receivers as noise. However, this noise can be strong enough to make a node defer from transmitting. As such, the fact that a radio treats transmissions it cannot receive as noise is the mechanism that allows any wireless protocol models to interfere with each other.

In reality and INET, both 802.11 and 802.15.4 employ the Clear Channel Assessment (CCA) technique (they listen to the channel to make sure there are no ongoing transmissions before starting to transmit) and defer from transmitting for the duration of a backoff period when the channel is busy. The use of CCA and backoff enables the two technologies to coexist cooperatively (both of them can communicate successfully), as opposed to destructively (they ruin each other’s communication). In our case, the nodes of the different technologies sense when the other kind is transmitting, and tend not to interrupt each other.

Here are some duration values in the example simulation, for both 802.11 and 802.15.4 (sending 1000B application packets with 24 Mbps, and 88B application packets with 250 kbps, respectively):

	802.11	802.15.4
Data	382 us	4192 us
SIFS	10 us	192 us
ACK	34 us	352 us
Backoff (avg)	600 us	1200 us

An 802.15.4 data frame transmission takes about ten times more than an 802.11 one, even though the payload is about ten times smaller. The SIFS and ack together are also about ten times longer in 802.15.4. The relative duration of transmissions of the Wifi and the WPAN is illustrated with the sequence chart below. The chart shows a packet transmission and ACK, first for the Wifi and then for the WPAN. The scale is linear.

Transmissions are protected within a particular wireless technology, i.e. nodes receiving a data frame can infer how long the transmission of the data frame and the subsequent ACK will be, from the data frame’s MAC header. They assume the channel is busy for the duration of the DATA + SIFS + ACK (thus they don’t start transmitting during the SIFS). However, this protection mechanism doesn’t work with the transmissions of other technologies, since nodes cannot receive and make sense of the MAC header. They just detect some signal power in the channel that makes them defer for the duration of a backoff period (but this duration is independent of the actual duration of the ongoing transmission). Also, neither technology performs CCA before sending an ACK. Thus they are susceptible for transmitting into each others’ ACKs, which can lead to more retransmissions.

Also, the hidden node protection mechanism in 802.11 relies on the successful reception of RTS and CTS frames, so hidden node protection might not work in a multi-technology wireless environment.

Configuration

The simulation uses the CoexistenceShowcase network, defined in CoexistenceShowcase.ned:

The network contains four AdhocHost’s. Two of the hosts, wifiHost1 and wifiHost2, communicate via 802.11, in ad hoc mode. The other two hosts, wpanHost1 and wpanHost2, communicate via 802.15.4. The four hosts are arranged in a rectangle, and all of them are in communication range with each other (corresponding hosts are 20 meters apart). One host in each host pair sends frames to the other (wifiHost1 to wifiHost2, and wpanHost1 to wpanHost2).

The General configuration in omnetpp.ini contains the radio, radio medium and visualizer settings. The radio medium module in the network is a RadioMedium. It is configured to use the DimensionalAnalogModel. The background noise type is set to IsotropicDimensionalBackgroundNoise, with a power of -110 dBm. Here is the radio medium configuration in omnetpp.ini:

*.radioMedium.analogModel.typename = "DimensionalAnalogModel"
*.radioMedium.backgroundNoise.typename = "IsotropicDimensionalBackgroundNoise"
*.radioMedium.backgroundNoise.powerSpectralDensity = -113dBmWpMHz

The Wifi hosts are configured to have Ieee80211DimensionalRadio. The default timeGains parameter is not changed in the transmitter, so the radio uses a flat signal in time. In frequency, instead of the default flat signal, we configure a more realistic shape. We’ll use the 802.11 OFDM spectral mask, as in the standard:

Here is the frequencyGains parameter value specifying this spectrum:

*.wifiHost*.wlan[*].radio.transmitter.frequencyGains = "left c-b*1.5 -40dB linear c-b -28dB linear c-b*0.5-1MHz -20dB linear c-b*0.5+1MHz 0dB linear c+b*0.5-1MHz 0dB linear c+b*0.5+1MHz -20dB linear c+b -28dB linear c+b*1.5 -40dB right"

Briefly about the syntax:

• The parameter uses frequency and gain pairs to define points on the frequency/gain graph. c is the center frequency and b is the bandwidth. These values are properties of the transmission, i.e. the receiver listens on the frequency band defined by the center frequency and bandwidth. However, the signal can have radio energy outside of this range, which can cause interference.

• Between these points, the interpolation mode can be specified, e.g. left (take value of the left point), greater (take the greater of the two points), linear, etc.

• The -inf Hz/-inf dB and the +inf Hz/+inf dB points are implicit (hence the frequencyGains string starts with an interpolation mode).

For more on the syntax, see DimensionalTransmitterBase.

Also we set the snirThresholdMode parameter in the radio’s receiver module, and the snirMode parameter in the error model to mean:

*.*Host*.wlan[*].radio.receiver.snirThresholdMode = "mean"
*.*Host*.wlan[*].radio.receiver.errorModel.snirMode = "mean"

In the receiver module, reception of frames under the SNIR threshold is not attempted (they’re discarded). The snirThresholdMode specifies how the SNIR threshold is calculated. The parameter’s value is either mean or min, i.e. either take the minimum or the mean of the SNIR during the reception.

The SNIR is important for calculating reception; the error model uses it to decide if the reception was successful. In the error model, the snirMode parameter specifies how the SNIR is computed when the receiver attempts to receive a frame; also either min or mean. When calculating with the minimum of the SNIR during the reception, a short spike in the interfering signal might ruin the reception, as it can decrease the SNIR substantially. Inversely, when two signals overlap substantially but not entirely (in either time or frequency), the mean SNIR might not be low enough to ruin the reception (when in this case it would be more realistic if it did).

We set the snirMode to mean because concurrent Wifi and WPAN signals don’t overlap significantly in the time-frequency space. That is, the WPAN frame’s spectrum is much smaller than the Wifi’s; similarly, the Wifi frame is much shorter than the WPAN.

The Wifi channel is set to Channel 9 (center frequency of 2452MHz) to ensure that the Wifi transmissions overlap with the 802.15.4 transmissions in frequency. Here is the configuration for the Wifi host radios in omnetpp.ini:

*.wifiHost*.wlan[*].radio.typename = "Ieee80211DimensionalRadio"
*.wifiHost*.wlan[*].radio.channelNumber = 8

Note

The channel number is set to 8 because in INET’s 802.11 model, the channels are numbered from 0, so that this setting corresponds to Wifi Channel 9.

The WPAN hosts are configured to have an Ieee802154NarrowbandInterface, with a Ieee802154NarrowbandDimensionalRadio. As in the case of the Wifi hosts, the default flat signal shape is used in time. In frequency, we’ll use a more realistic shape, based on the modulated spectrum of the CC2420 Zigbee transmitter:

We’ll use the approximation indicated with red. Here is the frequencyGains parameter value specifying this spectrum:

*.wpanHost*.wlan[*].radio.transmitter.frequencyGains = "left c-5MHz -40dB linear c-2MHz -20dB linear c-1MHz 0dB either c+1MHz 0dB linear c+2MHz -20dB linear c+5MHz -40dB right"

The default carrier frequency (2450 MHz) and bandwidth (2.8 MHz) is not changed. Here is the configuration for the WPAN host radios in omnetpp.ini:

*.wpanHost*.wlan[*].typename = "Ieee802154NarrowbandInterface"
*.wpanHost*.wlan[*].radio.typename = "Ieee802154NarrowbandDimensionalRadio"

The transmission power parameters for both technologies are left on default (20 mW for the Wifi and 2.24 mW for the WPAN). The Wifi hosts operate in the default 802.11g mode and use the default data bitrate of 24 Mbps. The WPAN hosts use the default bitrate of 250 kbps (specified in Ieee802154Mac).

The traffic for the Wifi hosts is contained in the WifiHosts configuration. wifiHost1 is configured to send a 1000-byte UDP packet to wifiHost2 every 0.4 milliseconds, corresponding to about 20 Mbps traffic, saturating the Wifi channel. Here is the Wifi traffic configuration in omnetpp.ini:

[Config WifiHosts]
# wifi hosts app settings
*.wifiHost1.numApps = 1
*.wifiHost1.app[*].typename = "UdpBasicApp"
*.wifiHost1.app[*].destAddresses = "wifiHost2"
*.wifiHost1.app[*].destPort = 5000
*.wifiHost1.app[*].messageLength = 1000byte
*.wifiHost1.app[*].packetName = "UDPData-wifi"
*.wifiHost1.app[*].startTime = uniform(0.1us, 0.1s)
*.wifiHost1.app[*].sendInterval = 0.4ms

*.wifiHost2.numApps = 1
*.wifiHost2.app[*].typename = "UdpSink"
*.wifiHost2.app[*].localPort = 5000

The traffic for the Wpan hosts is contained in the WpanHosts configuration. wpanHost1 is configured to send an 88-byte UDP packet to wpanHost2 every 0.1 seconds, which is about 7 Kbps of traffic (the packet size is set to 88 bytes in order not to exceed the default maximum transfer unit in 802.15.4). Here is the WPAN traffic configuration in omnetpp.ini:

[Config WpanHosts]
# wpan hosts app settings
*.wpanHost1.numApps = 1
*.wpanHost1.app[0].typename = "UdpBasicApp"
*.wpanHost1.app[0].destAddresses = "wpanHost2"
*.wpanHost1.app[0].destPort = 5000
*.wpanHost1.app[0].messageLength = 88byte
*.wpanHost1.app[0].packetName = "UDPData-wpan-"
*.wpanHost1.app[0].startTime = uniform(0.1us, 0.1s)
*.wpanHost1.app[0].sendInterval = 0.1s

*.wpanHost2.numApps = 1
*.wpanHost2.app[0].typename = "UdpSink"
*.wpanHost2.app[0].localPort = 5000

The independent performance data can be obtained by running the WifiHosts and the WpanHosts configurations in omnetpp.ini, as they each contain just one type of hosts (Wifi or Wpan).

To specify the case where they both coexist, the Coexistence configuration extends both WifiHosts and WpanHosts:

[Config Coexistence]
extends = WifiHosts, WpanHosts

In all configurations, the simulations are run for five seconds and repeated eight times.

Results

There is contention between the Wifi and WPAN hosts so that it is expected that they will be able to coexist cooperatively. However, protection mechanisms don’t work between the two technologies, so it is likely that they’ll transmit into each other’s transmissions, and the performance of both will be degraded. The Wifi host waits less than the WPAN host before accessing the channel, so it is expected that the Wifi host will gain channel access most of the time. The Wifi might even starve the WPAN.

WPAN transmissions are significantly longer than Wifi transmissions, thus, when the WPAN host does gain channel access, it’ll take lots of air time from the Wifi host during the transmission of a single 802.15.4 frame. However, the WPAN host sends frames much less frequently than the Wifi host, so it can afford to wait for channel access; its performance might be mostly unaffected. Also, the Wifi host’s transmission power is significantly greater than the WPAN host’s, so that when the two transmit concurrently, the Wifi transmission might be correctly receivable but the WPAN transmission might be corrupted.

The simulation can be run by choosing the Coexistence configuration from omnepp.ini. It looks like the following when the simulation is run:

The Wifi hosts have the MAC contention state, and the WPAN hosts have the MAC state displayed above them, using InfoVisualizer. The spectrum and power of received signals is visualized with a spectrum figure (part of MediumVisualizer) at all hosts. The spectrum figure displays the sum of all signals present at the receiving node. Signals not being received are indicated with blue. When receiving a signal, the received signal is indicated with green; the sum of interfering signals are indicated with red. Note that the spectrum figure configures its scale automatically based on the signals displayed; also, all spectrum figures use the same scale so that the signal spectra and power levels can be compared.

The Wifi and WPAN hosts detect each others’ transmissions (but cannot receive them), and this causes them to defer from transmitting. Sometimes they transmit at the same time, and the transmissions interfere. However, the interference doesn’t ruin the receptions.

The reason is that the overlap in the time-frequency space is not large. The two transmissions overlap in frequency, but it is not substantial from the perspective of the Wifi (the WPAN transmission’s spectrum is small compared to the Wifi’s). Similarly, the transmissions overlap in time, but the overlap is not substantial from the perspective of the WPAN (the Wifi transmission’s duration is small compared to the WPAN’s). (Despite the low time-frequency space overlap, if the signal power for one of the transmissions were significantly higher than the other, the lower power transmission might not be correctly receivable.)

In the video, wifiHost1 and wpanHost1 transmit concurrently. The Wifi transmission is correctly received and successfuly ACKED. Then, wifiHost2 senses the ongoing WPAN transmission, and defers from transmitting. The WPAN tranmission is correctly received by wpanHost2. When the transmission is over, wifiHost1 sends its next frame; since ACKs are not protected by CCA, wpanHost2 sends the ACK concurrently with the Wifi frame (and also the Wifi ACK). All frames are correctly received; wifiHost1 waited for the remainder of the WPAN transmission, during which it could have sent multiple frames.

We examine the performance of the two technologies by looking at the number of received UDP packets at wifiHost2 and wpanHost2. We look at the independent performance of the Wifi and WPAN hosts (i.e. when there is just one of the host pairs communicating), and see how their performance changes when both of them communicate concurrently.

Here are the performance results:

In this particular scenario, the performance of Wifi is decreased by about 5 percent compared to the base performance. The performance of WPAN didn’t decrease, because it had packets to send infrequently; it could send them all despite the Wifi traffic. Note that the fractional number of packets is due to the averaging of the repetitions.

In this scenario, the transmissions of both technologies could be received correctly when interfering with each other. The decrease in performance comes from the fact that hosts defer from transmitting when they detect ongoing transmissions.

Sources: omnetpp.ini, CoexistenceShowcase.ned

Try It Yourself

If you already have INET and OMNeT++ installed, start the IDE by typing omnetpp, import the INET project into the IDE, then navigate to the inet/showcases/wireless/coexistence folder in the Project Explorer. There, you can view and edit the showcase files, run simulations, and analyze results.

Otherwise, there is an easy way to install INET and OMNeT++ using opp_env, and run the simulation interactively. Ensure that opp_env is installed on your system, then execute:

$ opp_env run inet-4.2 --init -w inet-workspace --install --chdir \
   -c 'cd inet-4.2.*/showcases/wireless/coexistence && inet'

This command creates an inet-workspace directory, installs the appropriate versions of INET and OMNeT++ within it, and launches the inet command in the showcase directory for interactive simulation.

Alternatively, for a more hands-on experience, you can first set up the workspace and then open an interactive shell:

$ opp_env install --init -w inet-workspace inet-4.2
$ cd inet-workspace
$ opp_env shell

Inside the shell, start the IDE by typing omnetpp, import the INET project, then start exploring.

Discussion

Use this page in the GitHub issue tracker for commenting on this showcase.

Table Of Contents

• Coexistence of IEEE 802.11 and 802.15.4
  • Goals
  • The Model
    • Configuration
  • Results
  • Try It Yourself
  • Discussion

Previous

Power Consumption

Next

Wireless Signal Analog Domain Representations