Page 152 shows under Green field mode:
L-STF | HT-LTF1 | HT-SIG | HT-LTF | DATA
This is green field so "L-STF" looks to be wrong and another error. It should be "HT GF STF"
Looking for a confirmation from CWNP.
I'n not able to answer your question but .....
My last company, Zebra, supported Green Field on their /n radios (which means we had to test it too - ugh).
They have tens of thousands of units in the field, but I'd never heard of a single customer configuring a Green Field network. Which seems to mimic most of the industry wisdom.
The IEEE seems to have learned from that, and they didn't bother to include it for /ac - although Zebra still supports it for /n mode in their /ac radios.
Wouldn't it make sense to support green field n today? At this point there shouldn't be any a, b, or g devices in use. I would love to have a switch to turn off backwards compatibility beyond n.
One benefit would be 20MHz wide preambles on 2.4GHz making 1,5,9,13 usable here in Europe.
Yes, you can make this argument, but I would prefer to leave it up to the company building/configuring the network.
Anytime you prohibit an older technology, you are forcing its replacement. Why force every small company to replace perfectly good equipment with more expensive gear, if it will not improve their bottom line ?
There are literally millions of handheld scanners and printers, and all of them work just fine at 2 Mbps, or less. And yes, I've measured and compared hundreds of devices to confirm it.
High rates, by themselves, will never be required for them to function - unless you prohibit the lower rates.
Granted, higher rates can improve network efficiency, and this can be important, but millions of devices do not NEED higher rates to perform their basic purpose. Printers, bar code readers, credit card scanners, etc., are limited by their physical limitations - like advancing the paper. The packet sizes are extremely small and, neglecting ACK's and quick status indicators, are only one-way input or output devices. Lower rates also require a lower SNR, and when you have large stores, parking lots, or humongous warehouses, range is still important.
I do agree that wireless software upgrades are nice, but this requires more CPU power (10x -100x) than most handheld devices contain. Comparatively, it takes almost no CPU power to print a label or scan a card.
Companies like Walmart buy 10,000 printers at a time, not ones or two's, and new roll-outs can be very expensive.
I don't know about Walmart, but I do know that supermarkets have low profit margins, usually less than 6%, and don't have extra cash for frills they don't think necessary.
Yes, I agree 100%. That's why I would love to a have switch for green field.
I know plenty of networks for start-ups established in the last 5 years who have absolutely no need for 22MHz preambles. There I could safely flip it to green field.
Well you can disable low "b" rates and for example in Cisco WLC there is an option to use "a/g" only under WLAN. That should get rid of DSSS and HR/DSSS Preambles and 22 MHz.
That is a common setting, but the APs usually still transmit the legacy preample just in case there are some other networks in vicinity. All data transmissions use OFDM, though. The green field specifically states that older standards are not accounted for. That's why I'd like to be able to switch it on when I know the environment is green field.
So you are saying even if all DSSS and HR/DSSS rates are disabled AP's will still transmit Premables on DSSS and HR/DSSS rates or DSSS-OFDM and HR/DSSS-OFDM ?
Yes, it is actually a requirement. Imagine you have two overlapping networks. For WLAN A you disable legacy support. There is no way the legacy devices on WLAN B could decode the preamble if it is sent as OFDM only. The devices would detect the energy, but they couldn't use the standard contention methods since they can't decode the transmission length in the header. That information is vital for other networks as well, not just yours. (Sometimes there are questions why the header is not encrypted. For the very same reason.)
I saw a discussion on this some where and I'll need to find it again to get the exact answer and check on it being a requirement. WLAN B can still use he Energy Detect though when it is doing CCA.