Bug 1016

I looked through the current codes related to preamble in WiFi and my understanding is that:

- It is currently hard-coded into MacLow that WifiPreamble is WIFI_PREAMBLE_LONG.
- The real use of WifiPreamble is at WifiPhy::CalculateTxDuration where it calls GetPlcpPreambleDurationMicroSeconds and GetPlcpHeaderDurationMicroSeconds.
- In these two functions, if the transmission mode is OFDM then the preamble will *always* calculated using OFDM preamble. If the transmission mode is DSSS, then it uses WIFI_PREAMBLE_LONG (as provided from MacLow).

So, it is my understanding that the code is already using OFDM Preamble for calculating transmission time. The preamble is not used for anything except for calculating transmission time. For example, if an 802.11g device sends a frame with OFDM preamble, 802.11b devices on the same channel will receive the frame even though 802.11b does not support OFDM.

I think these issues are relevant only in a simulation with mixed WiFi standards (802.11b/g). I'm not sure if this scenario is interesting to general users or not.

For a fully supported preamble, these changes are needed:

1. We need GetPreample function like GetRts/Cts/Data/AckMode at WifiRemoteStationMananger.
2. MacLow should call GetPreamble after calling GetRts/Cts/Data/AckMode and use it (not hard coded).
3. (Yans)WifiPhy should be modified so that 802.11b cannot receive OFDM frames.

These changes are for starter, no change to GetRts/Cts/Data/AckMode is expected.

For the next step, if we decide to support protection mechanism (IEEE802.11-2012 9.23.2) in 802.11b/g mixed scenario:

1. WifiRemoteStationManager and ManagementHeader have to be modified so that
  1.1 WifiRemoteStationManager is aware of a device that supports only 802.11b
  1.2 ManagementHeader needs to have NonErp_device and UseProtection bits
2. GetRts/Cts/Data/AckMode have to be modified so that they return the mode according to 9.23.2.

(In reply to comment #1)
> GetPlcpHeaderDurationMicroSeconds.
> - In these two functions, if the transmission mode is OFDM then the preamble
> will *always* calculated using OFDM preamble. If the transmission mode is DSSS,
> then it uses WIFI_PREAMBLE_LONG (as provided from MacLow).
> 
> So, it is my understanding that the code is already using OFDM Preamble for
> calculating transmission time. 


one fact is that the current code does not support the simulation of the DSSS-OFDM mode mentioned in section 19.3.6 of the standard. 
I mean, there is no such WifiMode, and no corresponding TX time calculation. 

But I start wondering if we really need the OFDM preamble at all. After all, we already have WIFI_MOD_CLASS_DSSS_OFDM, and we could use this to solve the lack of DSSS-OFDM WifiMode that I just mentioned. 

 

> 
> For a fully supported preamble, these changes are needed:
> 
> 1. We need GetPreample function like GetRts/Cts/Data/AckMode at
> WifiRemoteStationMananger.

I wonder if it would make more sense to just embed the preamble in WifiMode, and simplify the signature of many wifi functions. This way you wouldn't need to add the GetPreamble methods. What do you think?

We should also eventually consider if preamble should go into TX vector instead, see bug 917.


> 2. MacLow should call GetPreamble after calling GetRts/Cts/Data/AckMode and use
> it (not hard coded).

I agree that eventually it would be nice to support the configuration of the long/short preamble for .11b, instead of having it hardcoded. 


> 3. (Yans)WifiPhy should be modified so that 802.11b cannot receive OFDM frames.

I see this as a separate feature. Instead of just filtering by modulation type, you might want to go one step further and only allowing reception if the WifiMode being used is in the Supported Rates set. We don't necessarily need to use the preamble for this.

(In reply to comment #2)
> (In reply to comment #1)
> > GetPlcpHeaderDurationMicroSeconds.
> > - In these two functions, if the transmission mode is OFDM then the preamble
> > will *always* calculated using OFDM preamble. If the transmission mode is DSSS,
> > then it uses WIFI_PREAMBLE_LONG (as provided from MacLow).
> > 
> > So, it is my understanding that the code is already using OFDM Preamble for
> > calculating transmission time. 
> 
> 
> one fact is that the current code does not support the simulation of the
> DSSS-OFDM mode mentioned in section 19.3.6 of the standard. 
> I mean, there is no such WifiMode, and no corresponding TX time calculation. 
> 
> But I start wondering if we really need the OFDM preamble at all. After all, we
> already have WIFI_MOD_CLASS_DSSS_OFDM, and we could use this to solve the lack
> of DSSS-OFDM WifiMode that I just mentioned.

My understanding is that DSSS-OFDM = PLCP with DSSS (long/short) and actual transmission with OFDM. This *should* enable 802.11b devices to receive and understand PLCP Header but not the actual frame. I think that the LENGTH field in the PLCP header will cause 802.11b devices to defer access to the channel even though they cannot actually receive the frame. That would be one way of letting 802.11b and g operate concurrently.

802.11g devices can also use RTS/CTS with DSSS and DATA frame with OFDM (both PLCP and actual frame).

> 
> 
> 
> > 
> > For a fully supported preamble, these changes are needed:
> > 
> > 1. We need GetPreample function like GetRts/Cts/Data/AckMode at
> > WifiRemoteStationMananger.
> 
> I wonder if it would make more sense to just embed the preamble in WifiMode,
> and simplify the signature of many wifi functions. This way you wouldn't need
> to add the GetPreamble methods. What do you think?
> 
> We should also eventually consider if preamble should go into TX vector
> instead, see bug 917.

I agree. We can embed the preamble in WifiMode. That way we don't need to do two separate calls for WifiMode and Preamble.

> 
> 
> > 2. MacLow should call GetPreamble after calling GetRts/Cts/Data/AckMode and use
> > it (not hard coded).
> 
> I agree that eventually it would be nice to support the configuration of the
> long/short preamble for .11b, instead of having it hardcoded. 
> 
> 
> > 3. (Yans)WifiPhy should be modified so that 802.11b cannot receive OFDM frames.
> 
> I see this as a separate feature. Instead of just filtering by modulation type,
> you might want to go one step further and only allowing reception if the
> WifiMode being used is in the Supported Rates set. We don't necessarily need to
> use the preamble for this.

I agree. That would be a good thing to have in a simulation. My question is how it works for DSSS-OFDM transmission where PLCP can be received but the actual frame cannot be received by 802.11b devices. Do we consider them busy receiving only for the PLCP duration or just simply consider them idle the whole time since they cannot receive the frame anyway.

I believe this topic is related to this bug as it affects the choice of Preamble a device can use.

I think 802.11g can operate in multiple ways depending on the environment:

1.) g sending to g with no b around: ERP-OFDM for all preamble/frames
2.) g sending to any: DSSS-OFDM (DSSS preamble + OFDM frame)
3.) g sending to g with b around:
  3.1) RTS/CTS with DSSS and DATA with ERP-OFDM
  3.2) CTS with DSSS to self

Case 3 is optional. 802.11g devices need to know that there are 802.11b around. I think getting that information is currently not supported. The related fields are NonErp_Present bit and Use_Protection bit.

An access point must set an NonErp_Present bit in a beacon to 1 if there is an 802.11b device associated with the AP. Other than that, the spec does not require setting NonErp_Present bit (it recommends some cases). Even if the NonErp_Present bit is setted, the Use_Protection bit is not necessarily setted.

I think case 1) and 2) can be done without much effort. Case 3) is likely to be more involved as it requires detecting an 802.11b device and working with beacon frames.

(In reply to comment #2)
> (In reply to comment #1)
> > GetPlcpHeaderDurationMicroSeconds.
> > - In these two functions, if the transmission mode is OFDM then the preamble
> > will *always* calculated using OFDM preamble. If the transmission mode is DSSS,
> > then it uses WIFI_PREAMBLE_LONG (as provided from MacLow).
> > 
> > So, it is my understanding that the code is already using OFDM Preamble for
> > calculating transmission time. 
> 
> 
> one fact is that the current code does not support the simulation of the
> DSSS-OFDM mode mentioned in section 19.3.6 of the standard. 
> I mean, there is no such WifiMode, and no corresponding TX time calculation. 
> 
> But I start wondering if we really need the OFDM preamble at all. After all, we
> already have WIFI_MOD_CLASS_DSSS_OFDM, and we could use this to solve the lack
> of DSSS-OFDM WifiMode that I just mentioned. 
> 

I looked through the code again and start wondering about how DSSS-OFDM would work in the simulation. I mean, the point of DSSS-OFDM is that 802.11b devices can understand PLCP header since it is sent using DSSS but cannot understand the actual MAC frame. Since the device understands PLCP header, it defers access to the medium by the time as specified by the LENGTH field in the PLCP header (not the same as NAV, which starts after the MAC frame is received).

How would that work for the current implementation? The current code takes both PLCP header at the same time at _the end_ of MAC frame transmission. Should we consider taking care of them separately? I can imagine that it would be very invasive to the code. We can still do the same but have a new ReceiveErrorUnsupported call for events like this.

In other note, I think embed preamble/plcp into WifiMode may not be a good idea as the preamble/plcp themselves are also wifi mode.

 
> How would that work for the current implementation? The current code takes
> both PLCP header at the same time at _the end_ of MAC frame transmission.
> Should we consider taking care of them separately? I can imagine that it
> would be very invasive to the code. 

Indeed separating the PLCP header reception from the preamble reception would be a very big change. Something like a new (separate?) WifiPhy model. So until someone explicitly volunteers for this, we can just forget it.


> We can still do the same but have a new
> ReceiveErrorUnsupported call for events like this.

But would a real .11b device detect that there is a wifi signal that it does not support? Or would it just fail to receive it without knowing why? In the latter case, we could just use the current code for EndReceive in the erroneous case.


> In other note, I think embed preamble/plcp into WifiMode may not be a good
> idea as the preamble/plcp themselves are also wifi mode.

ah yes good point, I had forgotten this.

Re-reading this after a long time, my feeling is that we might just leaving the code as-is, since pure OFDM is handled ok, and only mixed .11b/g simulations seem to need modifications. Anyway, I suggest to check with the current code to be sure.

This bug can be closed, there is no need for an additional OFDM preamble (also confirmed by other developers/maintainers in previous discussions).

Other discussed points in this thread:
802.11b/g coexistence => tracked by bug 2120 (a fix is almost ready to be sent for review).
Support for short PLCP iso being hardcoded => recently delivered in the code.
Separation of the PLCP header reception from the preamble reception: ongoing work by Farah Nadeem, code is expected to be delivered in the coming months.