Talk:List of WLAN channels

Outdated 5GHz section

The 5GHz section is woefully out of date. Here is a summary of the current regulatory domains (from Linux regdb, July 2015):

            5000      5100      5200      5300      5400      5500      5600      5700      5800      5900
00 |         |         |      ████████████████       |        ███████████████████████████████████      | 
AD |         |         |      ████████████████       |        ██████████████████████         |         | Andorra
AE |         |         |      ████████████████       |        ███████████████████████████████████      | United Arab Emi
AF |         |         |      ████████████████       |        ██████████████████████         |         | Afghanistan
AI |         |         |      ████████████████       |        ██████████████████████         |         | Anguilla
AL |         |         |      ████████████████       |        ██████████████████████         |         | Albania
AM |         |         |      ████████████████       |         |         |         |         |         | Armenia
AN |         |         |      ████████████████       |        ██████████████████████         |         | Netherlands Ant
AR |         |         |      ████████████████       |        ███████████████████████████████████      | Argentina
AS |         |         |      ████████████████       |        ███████████████████████████████████      | American Samoa
AT |         |         |      ████████████████       |        ██████████████████████         |         | Austria
AU |         |         |      ████████████████       |        ██████████████████████  ███████████      | Coral Sea Islan
AW |         |         |      ████████████████       |        ██████████████████████         |         | Aruba
AZ |         |         |      ████████████████       |         |         |         |         |         | Nagorno-Karabak
BA |         |         |      ████████████████       |        ██████████████████████         |         | Bosnia and Herz
BB |         |         |      ████████████████       |         |         |         |  ███████████      | Barbados
BD |         |         |         |         |         |         |         |         |  ███████████      | Bangladesh
BE |         |         |      ████████████████       |        ██████████████████████         |         | Belgium
BF |         |         |      ████████████████       |        ███████████████████████████████████      | Burkina Faso
BG |         |         |      ████████████████       |        ██████████████████████ ████████████████  | Bulgaria
BH |         |         |      ████████████████       |         |         |         |  ███████████      | Bahrain
BL |         |         |      ████████████████       |        ██████████████████████         |         | 
BM |         |         |      ████████████████       |        ███████████████████████████████████      | Bermuda
BN |         |         |      ████████████████       |         |         |         |  ███████████      | Brunei
BO |         |         |         |    ████████       |         |         |         |  ███████████      | Bolivia
BR |         |         |      ████████████████       |        ███████████████████████████████████      | Brazil
BS |         |         |      ████████████████       |        ███████████████████████████████████      | Bahamas
BT |         |         |      ████████████████       |        ██████████████████████         |         | Bhutan
BY |         |         |      ████████████████       |        ██████████████████████         |         | Belarus
BZ |         |         |         |         |         |         |         |         |  ███████████      | Belize
CA |         |         |      ████████████████       |        ███████████████████████████████████      | Canada
CF |         |         |      ████████████████       |        ███████████████████████████████████      | Central African
CH |         |         |      ████████████████       |        ██████████████████████         |         | Switzerland
CI |         |         |      ████████████████       |        ███████████████████████████████████      | Cote d'Ivoire (
CL |         |         |      ████████████████       |         |         |         |  ███████████      | Chile
CN |         |         |      ████████████████       |         |         |         |  ███████████      | China
CO |         |         |      ████████████████       |        ███████████████████████████████████      | Colombia
CR |         |         |      ████████████████       |        ███████████████████████████████████      | Costa Rica
CX |         |         |      ████████████████       |        ███████████████████████████████████      | Christmas Islan
CY |         |         |      ████████████████       |        ██████████████████████         |         | Northern Cyprus
CZ |         |         |    ████████████████████     |      ██████████████████████████       |         | Czech Republic
DE |         |         |    ████████████████████     |      ██████████████████████████       |         | Germany
DK |         |         |      ████████████████       |        ██████████████████████         |         | Denmark
DM |         |         |      ████████████████       |         |         |         |  ███████████      | Dominica
DO |         |         |      ████████████████       |         |         |         |  ███████████      | Dominican Repub
DZ |         |         |      ████████████████       |        ██████████████████   |         |         | Algeria
EC |         |         |      ████████████████       |        ███████████████████████████████████      | Ecuador
EE |         |         |      ████████████████       |        ██████████████████████         |         | Estonia
EG |         |         |      ████████████████       |         |         |         |         |         | Egypt
ES |         |         |    ████████████████████     |      ██████████████████████████       |         | Spain
ET |         |         |      ████████████████       |        ██████████████████████         |         | Ethiopia
FI |         |         |      ████████████████       |        ██████████████████████         |         | Finland
FM |         |         |      ████████████████       |        ███████████████████████████████████      | Micronesia
FR |         |         |      ████████████████       |        ██████████████████████         |         | France
GB |         |         |      ████████████████       |        ██████████████████████         |         | United Kingdom
GD |         |         |      ████████████████       |        ███████████████████████████████████      | Grenada
GE |         |         |      ████████████████       |         |         |         |         |         | South Ossetia
GF |         |         |      ████████████████       |        ██████████████████████         |         | French Guiana
GH |         |         |      ████████████████       |        ███████████████████████████████████      | Ghana
GL |         |         |      ████████████████       |        ██████████████████████         |         | Greenland
GP |         |         |      ████████████████       |        ██████████████████████         |         | Guadeloupe
GR |         |         |      ████████████████       |        ██████████████████████         |         | Greece
GT |         |         |      ████████████████       |         |         |         |  ███████████      | Guatemala
GU |         |         |      ████████████████       |        ███████████████████████████████████      | Guam
GY |         |         |         |         |         |         |         |         |  ███████████      | Guyana
HK |         |         |      ████████████████       |        ██████████████████████  ███████████      | Hong Kong
HN |         |         |      ████████████████       |        ███████████████████████████████████      | Honduras
HR |         |         |      ████████████████       |        ██████████████████████         |         | Croatia
HT |         |         |      ████████████████       |        ███████████████████████████████████      | Haiti
HU |         |         |      ████████████████       |        ██████████████████████         |         | Hungary
ID |         |         |         |         |         |         |         |         |  █████████        | Indonesia
IE |         |         |      ████████████████       |        ██████████████████████         |         | Ireland
IL |         |         |    ████████████████████     |         |         |         |         |         | Israel
IN |         |         |      ████████████████       |         |         |         |  ███████████      | India
IR |         |         |         |         |         |         |         |         |  ███████████      | Iran
IS |         |         |      ████████████████       |        ██████████████████████         |         | Iceland
IT |         |         |      ████████████████       |        ██████████████████████         |         | Italy
JM |         |         |      ████████████████       |        ███████████████████████████████████      | Jamaica
JO |         |         |      ████████     |         |         |         |         |  ███████████      | Jordan
JP |████████ |  ██████ |      ████████████████       |        ██████████████████████         |         | Japan
KE |         |         |      ████████     |         |        ████████   |         |  █████  |         | Kenya
KH |         |         |      ████████████████       |        ██████████████████████         |         | Cambodia
KN |         |         |      ████████████████       |        ██████████████████████  █████████        | Saint Kitts and
KP |         |         |      ████████████████       |        ██████████████       |  █████████        | North Korea
KR |         |         |      ████████████████       |        ██████████████████████  ███████████      | South Korea
KW |         |         |      ████████████████       |         |         |         |         |         | Kuwait
KY |         |         |      ████████████████       |        ███████████████████████████████████      | Cayman Islands
LB |         |         |      ████████████████       |        ███████████████████████████████████      | Lebanon
LC |         |         |      ████████████████       |        ██████████████████████  █████████        | Saint Lucia
LI |         |         |      ████████████████       |        ██████████████████████         |         | Liechtenstein
LK |         |         |      ████████████████       |        ███████████████████████████████████      | Sri Lanka
LS |         |         |      ████████████████       |        ██████████████████████         |         | Lesotho
LT |         |         |      ████████████████       |        ██████████████████████         |         | Lithuania
LU |         |         |      ████████████████       |        ██████████████████████         |         | Luxembourg
LV |         |         |      ████████████████       |        ██████████████████████         |         | Latvia
MA |         |         |      ████████████████       |         |         |         |         |         | Morocco
MC |         |         |      ████████████████       |        ██████████████████████         |         | Monaco
MD |         |         |      ████████████████       |        ██████████████████████         |         | Pridnestrovie (
ME |         |         |      ████████████████       |        ██████████████████████         |         | Montenegro
MF |         |         |      ████████████████       |        ██████████████████████         |         | 
MH |         |         |      ████████████████       |        ███████████████████████████████████      | Marshall Island
MK |         |         |      ████████████████       |        ██████████████████████         |         | Macedonia
MN |         |         |      ████████████████       |        ███████████████████████████████████      | Mongolia
MO |         |         |      ████████████████       |        ███████████████████████████████████      | Macau
MP |         |         |      ████████████████       |        ███████████████████████████████████      | Northern Marian
MQ |         |         |      ████████████████       |        ██████████████████████         |         | Martinique
MR |         |         |      ████████████████       |        ██████████████████████         |         | Mauritania
MT |         |         |      ████████████████       |        ██████████████████████         |         | Malta
MU |         |         |      ████████████████       |        ███████████████████████████████████      | Mauritius
MV |         |         |    ████████████████████     |         |         |         | █████████████     | Maldives
MW |         |         |      ████████████████       |        ██████████████████████         |         | Malawi
MX |         |         |      ████████████████       |        ███████████████████████████████████      | Mexico
MY |         |         |      ████████████████       |         |         |         |  ███████████      | Malaysia
NG |         |         |         |    ████████       |         |         |         |  ███████████      | Nigeria
NI |         |         |      ████████████████       |        ███████████████████████████████████      | Nicaragua
NL |         |         |      ████████████████       |        ██████████████████████         |         | Netherlands
NO |         |         |    ████████████████████     |      █████████████████████████████████|████     | Norway
NP |         |         |      ████████████████       |         |         |         |  ███████████      | Nepal
NZ |         |         |      ████████████████       |        ███████████████████████████████████      | New Zealand
OM |         |         |      ████████████████       |        ██████████████████████         |         | Oman
PA |         |         |      ████████████████       |         |         |         |  ███████████      | Panama
PE |         |         |      ████████████████       |        ███████████████████████████████████      | Peru
PF |         |         |      ████████████████       |        ██████████████████████         |         | Clipperton Isla
PG |         |         |      ████████████████       |        ███████████████████████████████████      | Papua New Guine
PH |         |         |      ████████████████       |        ███████████████████████████████████      | Philippines
PK |         |         |         |         |         |         |         |         |  ███████████      | Pakistan
PL |         |         |      ████████████████       |        ██████████████████████         |         | Poland
PM |         |         |      ████████████████       |        ██████████████████████         |         | Saint Pierre an
PR |         |         |      ████████████████       |        ███████████████████████████████████      | Puerto Rico
PT |         |         |      ████████████████       |        ██████████████████████         |         | Portugal
PW |         |         |      ████████████████       |        ███████████████████████████████████      | Palau
PY |         |         |      ████████████████       |        ███████████████████████████████████      | Paraguay
QA |         |         |         |         |         |         |         |         |  ███████████      | Qatar
RE |         |         |      ████████████████       |        ██████████████████████         |         | Reunion
RO |         |         |      ████████████████       |        ██████████████████████         |         | Romania
RS |         |         |    ████████████████████     |      ██████████████████████████       |         | Serbia
RU |         |         |      ████████████████       |         |         |    ███████████████████      | Russia
RW |         |         |      ████████████████       |        ███████████████████████████████████      | Rwanda
SA |         |         |      ████████████████       |        ██████████████████████         |         | Saudi Arabia
SE |         |         |      ████████████████       |        ██████████████████████         |         | Sweden
SG |         |         |      ████████████████       |        ███████████████████████████████████      | Singapore
SI |         |         |      ████████████████       |        ██████████████████████         |         | Slovenia
SK |         |         |      ████████████████       |        ██████████████████████         |         | Slovakia
SN |         |         |      ████████████████       |        ███████████████████████████████████      | Senegal
SR |         |         |      ████████████████       |        ██████████████████████         |         | Suriname
SV |         |         |      ████████████████       |         |         |         |  ███████████      | El Salvador
TC |         |         |      ████████████████       |        ███████████████████████████████████      | Turks and Caico
TD |         |         |      ████████████████       |        ██████████████████████         |         | Chad
TG |         |         |      ████████████████       |        ██████████████████████         |         | Togo
TH |         |         |      ████████████████       |        ███████████████████████████████████      | Thailand
TN |         |         |      ████████████████       |         |         |         |         |         | Tunisia
TR |         |         |      ████████████████       |        ██████████████████████         |         | Turkey
TT |         |         |      ████████████████       |        ███████████████████████████████████      | Trinidad and To
TW |         |         |         |      ██████       |        ██████████ |    ██████  ███████████      | Taiwan
TZ |         |         |         |         |         |         |         |         |  ███████████      | Tanzania
UA |         |         |    ████████████████████     |        ██████████████████   |  ███████████      | Ukraine
UG |         |         |      ████████████████       |        ███████████████████████████████████      | Uganda
US |         |         |      ████████████████       |        ███████████████████████████████████      | United States
UY |         |         |      ████████████████       |        ███████████████████████████████████      | Uruguay
UZ |         |         |      ████████████████       |         |         |         |         |         | Uzbekistan
VC |         |         |      ████████████████       |        ██████████████████████         |         | Saint Vincent a
VE |         |         |      ████████████████       |         |         |         |  ███████████      | Venezuela
VI |         |         |      ████████████████       |        ███████████████████████████████████      | U.S. Virgin Isl
VN |         |         |      ████████████████       |        ███████████████████████████████████      | Vietnam
VU |         |         |      ████████████████       |        ███████████████████████████████████      | Vanuatu
WF |         |         |      ████████████████       |        ██████████████████████         |         | Wallis and Futu
WS |         |         |      ████████████████       |        ██████████████████████         |         | Samoa
YT |         |         |      ████████████████       |        ██████████████████████         |         | Mayotte
ZA |         |         |      ████████████████       |        ██████████████████████         |         | South Africa
ZW |         |         |      ████████████████       |        ██████████████████████         |         | Zimbabwe
            5000      5100      5200      5300      5400      5500      5600      5700      5800      5900

Reason for page

I'm adding this because this information is missing from wikipedia. 802.11a channel/frequency mapping is difficult to find and I expected to find it from Wikipedia. Information on channel/frequency mappings should be readily available. I'm hoping this article will find a better place or name, but still exist in wikipedia, preferably 802.11a/b/g/n channels all on one page. --Joneskoo 16:45, 22 September 2007 (UTC)

I'd also like to get references to some document that defines this channel naming scheme. Apparently on 5 GHz it is 5000 MHz + channel * 5 MHz, for example channel 36 = 5000 MHz + 36 * 5 MHz. I used http://www.moonblinkwifi.com/80211a_frequency_channel_map.cfm as a source but I'd really like some better reference to the article. --Joneskoo 16:48, 22 September 2007 (UTC)

IEEE 802.11-2012 § 18.3.8.4.2 provides that reference.J0boyers (talk) 05:28, 5 January 2013 (UTC)

France

Haven't the channel restrictions in France been removed in the meantime? 212.213.204.99 05:18, 2 November 2007 (UTC)

Find a verifiable source and change the text in the article. -- KelleyCook (talk) 20:51, 3 January 2008 (UTC)

Done - 82.123.102.83 (talk) 17:10, 13 March 2008 (UTC)

Israel

Maybe add Israel to the first table (channels 3-9)? 87.194.223.183 00:51, 4 December 2007 (UTC)

Give a definitive source (either a link to the Israeli law or an IEEE citation) and then it can go in. -- KelleyCook (talk) 22:04, 4 December 2007 (UTC)

admin 103.10.66.13 (talk) 12:06, 1 December 2023 (UTC)

More channels are now available for use in Israel (basically aligning with European regulations). Link provided by Israeli MOC as a response to my query: https://moj.my.salesforce.com/sfc/dist/version/download/?oid=00D1t000000uX5h&ids=0683Y00000DcoLF&d=%2Fa%2F3Y000000h5ea%2FljcftGq2yZ9bwH.XH1EkZx5WIaxd9o8YOEQh.lic3vM&asPdf=false

A copy is also available here: https://docs.google.com/document/d/1aswr4MGlTVpKcaYBwDp1oEUHxRJAxxT8/edit I would have updated the table but I don't want to risk it (not sure how to properly edit tables) — Preceding unsigned comment added by GilbsonLP (talk • contribs) 23:03, 16 January 2021 (UTC)

Wrong information

Please be careful regarding assertions of legally approved channels... (in the first section) References to 802.11 standards do not help much (not even 802.11-2007) as even this document is actually about three years old since I and 300+ other 802.11 members wrote it. Regulators (esp Japan and a couple of EU countries) have made changes to the channels in the last three years. To be crystal clear referencing 802.11 is not proper as it is not a regulatory organizarion and it lacks any legal authority to set channels. 802.11 merely reports what the status is at the time of the standards draft which is three or more years earlier them the date... I tried to make updates but now it appears that I am blocked and I do not want to refer to myself as an authority reveling who i am, less the regulatory rnvironmrnt change and litigation happen do to the section not being updated... —Preceding unsigned comment added by 76.118.191.206 (talk) 03:48, 2 January 2008 (UTC)

You're changes are not being blocked. The message I left on your talk page simply was stating that Wikipedia demands verifiable sources. I realize that by its very nature of being a multiple committee driven multi-year process, the IEEE 802.11-2007 information is out-of-date. It would be more than welcome to have newer and correct information. But any changes that you add needs to be verifiable, such as was included with the recent change to the Japan 5Ghz section. A secondary problem is that you can't put a blanket "This is Wrong information" statement, even if it is true, as it both has a NPOV stance and breaks the Wikipedia:No disclaimers in articles policy. The article already states three times that "These regulations are subject to change at any time." Let me make try and compromise by make that more topical -- KelleyCook (talk) 20:51, 3 January 2008 (UTC)

76.118.191.206 145.224.73.53 (talk) 22:00, 20 October 2023 (UTC)

Asia

Asia is not a regulatory domain!? Find me a country on this planet called "Asia" please remove it —Preceding unsigned comment added by 76.118.191.206 (talk) 18:28, 3 January 2008 (UTC)

Gone, next time please WP:Be bold -- KelleyCook (talk) 21:01, 3 January 2008 (UTC)

5GHz Channels in the US

According to http://www.fcc.gov/oet/info/rules/part15/part15-9-20-07.pdf page 130 the bands 5.15-5.25 are available for unlicensed use at 50mW, 5.25-5.35 and 5.47-5.725 at 250mW and 5.725-5.825 at 1W. Is there another reason channels 52-64 are listed as No for the US? (I'm no expert in RF so not editing the article) — Preceding unsigned comment added by 131.216.7.132 (talk) 23:02, 24 March 2008 (UTC)

On 2020-11-18, the FCC Adopted Report and Order FCC-20-164 which added 5.850-5.925 MHz to 47 CFR 15.401 for Wifi use https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 Mrdvt92 (talk) 14:53, 3 December 2020 (UTC)

Thanks for reporting this, I've now submitted a patch for this addition. -bkil (talk) 22:45, 3 December 2020 (UTC)

Spain has more channels

Spain, like the rest of Europe, allows channels 1-13 (instead of 10-11). I have found some places where it says it is only channel 10 and 11, and I don't know why.

According to note UN-85 in CNAF (spanish legal frequency table) you can use 2400-2483,5 MHz for indoor wireless data networks (100 mW EIRP). http://es.wikipedia.org/wiki/CNAF http://www.mityc.es/Telecomunicaciones/Secciones/Espectro/cnaf/

Moreover, any modern wifi equipment legally sold in Spain supports channels 1-13. —Preceding unsigned comment added by LatinSuD (talk • contribs) 15:56, 2 May 2008 (UTC)

I took out the two columns which someone edited back to the (out of date) 802.11 doco. Thanks for the reference. -- ~~ — Preceding unsigned comment added by GregGarner (talk • contribs) 19:36, 22 September 2009 (UTC)

DFS for 5GHz channels

There are some channels that have a special use case called DFS, and it would be a good enhancement of this page to list DFS only channels. My understanding is that 5.25~5.35GHz (Ch52~64) and 5.47~5.725GHz (Ch100~140) can only be used if you do DFS properly and have your radio licensed as being DFS compliant. Basically DFS means that the system detects someone using the channel (typically radar) and then moving to another channel. The FCC website has extensive information about DFS. GregGarner (talk) 19:40, 22 September 2009 (UTC)

DFS client operation does not require any special tests, and TCBs can certify them. It is the DFS owners (access points) that must be tested by FCC labs to be certified prior to sale. A February 20, 2013 meeting of the FCC Commission will approve a new NPRM opening an additional 110 MHz for operation under DFS rules. ~~petere83~~

22, 25 or 40 MHz bandwidth?

The '2.4 GHz (802.11b/g/n)' section mentions 25 MHz of channel separation, and the picture shows 22 MHz per channel bandwidth usage. However, the n version of the standard (802.11n) talks about 40 MHz of bandwidth. Should this be clarified here? Tim-mnm (talk) 14:51, 16 October 2009 (UTC)

According to IEEE 802.11n-2009 40 MHz is for double channel mode within 802.11n (max. 600 Mbit/s instead of 288.90). Concerning the 22/25 MHz bandwith per channel both numbers make sense: With 25 MHz one could use channel 1, 6 and 11 without overlap and with 22 MHz for each channel even four channels (1, 6, 11 and 14 – the boundary between 11 and 14 would be exactly 2473 MHz) should be usable without overlap. --Frequencyhopper (talk) 14:55, 23 December 2009 (UTC)

802.11b ist outdated since long, simply use the same modulation-modes as on 5GHz and also the same channel-spacing. That means you can use wifi-channel 1,5,9,13 (keep in mind that in the USA channel 13 has some limitations). Keep it clean for the User, do NOT name the 40MHZ-Channels by mid-frequency, name them by 20MHz fallback-channel. So tell the user to select channel 1 or channel 13 for 40MHz bandwidth on 2.4GHz wifi. In the USA you might tell them to use channel 1 or 9, if they do not jet have hardware that is legal on wifi-channel 13. --DG8FZ 16:26, 27 July 2015 (UTC)

Channel 14

Is it true that the use of channel 14 is restricted or even prohibited in most countries of the world mainly because it conflicts with the satellite phone services operated by Globalstar and Iridium which use the frequency range from 2483.5 MHz to 2500 MHz? --Frequencyhopper (talk) 22:13, 22 December 2009 (UTC)

I don't know about other countries but in the United States Globalstar has a proposal being reviewed for government approval to allow for only their APs to broadcast over channel 14 but also opening up channels 12 & 13 for general public use. JRey (talk) 18:06, 31 July 2014 (UTC)

The current diagram shows channel 14 for the U.S., but that isn't allowed by FCC regulations. I think the diagram needs updated to remove channel 14. — Preceding unsigned comment added by 192.55.20.36 (talk) 20:42, 27 April 2017 (UTC)

5GHz Channel 165 in the US

FCC 15.407 covers channels within 5.15-5.25GHz, 5.47-5.725GHz and 5.725-5.825GHz bands. Since the center frequency of channel 165 is at 5.825GHz, then part of the channel's spectrum will go outside the 5.825GHz band edge. I don't think channel 165 can be covered by FCC 15.407 [12]. The FCC 15.247 [8] rules include channels in band 5725-5850MHz. The channel #165 which spans from 5815MHz-5835Mhz is allowed in the US, but I think it should be covered by FCC 15.247 [8] instead of FCC 15.407 [12]. 5GHz (802.11a/h/j/n) table has reference to [12] in the header for United States. I think a reference to 15.247 [8] needs to be added to Channel 165. Comments?

On 2020-11-18, the FCC Adopted Report and Order FCC-20-164 which added 5.850-5.925 MHz to 47 CFR 15.401 for Wifi use https://www.fcc.gov/document/fcc-modernizes-59-ghz-band-improve-wi-fi-and-automotive-safety-0 Mrdvt92 (talk) 14:53, 3 December 2020 (UTC)

Cisco has been shipping 802.11 access points using channel 165 for a long time. They might not have the same maximum transmit power as the other ISM channels.~~petere83~~ — Preceding unsigned comment added by Petere83 (talk • contribs) 05:51, 20 January 2013 (UTC)

Disputed

The Myth of 1, 6, 11

This is my first ever edit on wikipedia, so forgive me if this is not the procedure to request changes to documents. Basically I'd like to point out a fallacy in the assumption that non-overlapping channels in the 2,4GHz band are the ideal channels to obtain the maximum throughput. Non-overlapping channels make sense if the physical limit on the throughput is the thermal noise from concurrent transmissions. For example I can have an RSSI of my desired signal -45dBm at the receiever and an interfering signal of -80dBm and so have an SINR of 35dB. As the 54Mbps mode needs an SNR of 21dB to be received this is ok from a thermal noise point of view

It should be noted that a CSMA-CA mechanism needs a definition of what it considers as an occupied channel, and this is defined by the "clear channel assessment" (CCA) function of the PHY layer. In 802.11bg the CCA is described as the following two steps

1. Try to synchronize to an 802.11 preamble and if the synchronization occurs the channel is flagged as occupied. This effectively means that the channel is considered as occupied if a signal is received at the limit of the receiver sensitivity. For 802.11g that receiver sensitivity for the 6Mbps BPSK (as used in the preamble of the WiFi signal) mode is -85dBm. Note that as the instantaneous SINR requirements for reception of the 6Mbps mode is 6dB and for the 54Mbps 64QAM mode is 23dB, this CCA is very conservative and even very distant 802.11 devices can prevent communications between two 802.11g devices that are close and the actual interference of the distant device would be well under the SINR requirements. 802.11n has some optional "green-fields" preamble with a different CCA function that is suppose to address this, but I currently know of no manufacturer that has implemented these 802.11n exclusive preambles.

2. If no signal is detected by step 1) perform an RMS power measurement and if the detected power is above the threshold (-65dBm defined in section 14.6.15.3 of IEEE 802.11-2007) signal that the channel is busy.

This two step process has some implications for WiFi frequency planning and in particular the myth that the best allocation is channels 1,6,11 only as common wisdom implies. As the CCA function itself limits the access to the channel rather than the SINR in most cases, using channels 1,6,11 only means that 2 APs that using the same channel are limited by a CCA threshold power of -85dBm, whereas for example if you could use the channels 1,2,7,8,13,14 instead then the distance between the same channel reuse might be 70% further and the CCA limitation on access to the channel between overlapping channels (like channels 1 and 2) is 20dB higher. In fact the best results, given the existing CCA function is to use all of the WiFi channel and maximize the distance first between identical channels, and second between overlapping channels. — Preceding unsigned comment added by 163.116.6.11 (talk) 13:22, 16 October 2012 (UTC)

Rebuttal: The Flaw in the 4-Channel Minimal-Overlap Scheme for 2.4 GHz

The fundamental flaw in using the 4-channel scheme is that the non-overlapping distance requirement applies to both APs and clients. If you refer to Cisco's 2004 Whitepaper several cases are presented where a client creates a CCA-Occpied condition on two or more APs using minimal-overlap channels even though the APs are physically separated past the point where the RMS of detected power is <-65dBm.

Err.. but does this really way up against loosing a whole 20MHz channel? Also, how does this relate to the fixed channel scheme of 36, 40, 44, 48, etc. in the 5GHz band? Do you propose changing this scheme as well? I've been using the 1, 5, 9, 13 scheme for a while, and one advantage is that 4 channels allows for easier cell separation, kind of related to the 4 colour problem. Seriously, I think this needs more discussion and I strongly urge that it be switched back to 1, 5, 9, 13! —James Haigh (talk) 2013-11-17T02:41:46Z

The article text "Leaving 3 or 4 channels clear between used channels is recommended to avoid interference.[4] The exact spacing required depends on the protocol and data rate selected as well as the electromagnetic environment where the equipment is used." already covers the consideration that different environments and use requirements may allow the use of a greater than 3 channel scheme. In your worst-case scenario you will have only 3 non-overlapping channels. Whether one can use 4 (or even more) channels with some overlap is dependent on better than worst-case scenarios. — Preceding unsigned comment added by 192.55.20.36 (talk) 19:28, 5 December 2013 (UTC)

References

UK 5GHz Channels

I've just been checking these channels. I believe the UK channels are dictated by IR2030 which specifies a band from 5500MHz to 5700MHz. I don't think there are any higher channels unless someone knows different? — Preceding unsigned comment added by Edlong (talk • contribs) 10:27, 18 January 2013 (UTC)

802.11-2012 Update

The first link at the bottom of the article, for 802.11-2007, brings one to the IEEE site. However, due to 802.11 having its latest conglomeration of updates and amendments published in May of 2012, it now goes to the proper 802.11-2012 standard document. What would be the proper way of updating the article to reference the 2012 standard rather than the (now obsolete) 2007 standard? Subclauses such as 19.4.2, which are referenced in the article, do not change, so that shouldn't be an issue. However, it should reference the current standard. This would be viewed as a significant change, so I figured I'd post here first.J0boyers (talk) 05:37, 5 January 2013 (UTC) On about March 9, 2013, the first draft of 802.11-2015 will complete initial working group letter ballot, incorporating 802.11-2012, 802.11ae-2012 and 802.11aa-2012. It should be noted that EU allows operation in 5.725-5.850 GHz under Short Range Device rules with 25 mW EIRP Transmit Power limit. You should also start carrying the 60 GHz band channels from 802.11ad, which was published December 28, 2012. — Preceding unsigned comment added by Petere83 (talk • contribs) 05:48, 20 January 2013 (UTC)

References

US 5 GHz Expansion

The FCC is going to expand the 5 GHz band to a continuous block from 5.150 to 5.925. Ploxhoi (talk) 22:56, 4 February 2013 (UTC)

According to , which was published AFTER , channels 120, 124, and 128 should probably be marked as unavailable in the US. This is because that rule states that "Devices will not transmit on channels which overlap the 5600 – 5650 MHz band.2" Would someone else like to comment on this before I make the change on the main page? Corydon76 (talk) 20:13, 15 May 2015 (UTC)

References

Broken link.

802.11-2007 Japan MIC Released the new 5 GHz band (W56). Bureau Veritas — ADT. Retrieved 2008-02-23. is broken! is there a way to get the information direct from http://www.soumu.go.jp/english/ Ministry of Internal Affairs and Communication. — Preceding unsigned comment added by 125.192.69.212 (talk) 03:34, 13 May 2014 (UTC)

2,4GHz: 40MHz channel 11

Is it realy a good idea to use just one 40MHz-channel (channel 3)? So the half of the band is not used. There is a second nonoverlapping one: 11. I know it interfers with channel 6 at 20Mhz. But I think it's more a reason not to use channel 6 (and may 5 instead). --Fabiwanne (talk) 08:19, 27 May 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on List of WLAN channels. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20081105163502/http://www.fcc.gov/oet/ea/presentations/files/oct05/Unlicensed_Devices_JD.pdf to http://www.fcc.gov/oet/ea/presentations/files/oct05/Unlicensed_Devices_JD.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 21:42, 21 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on List of WLAN channels. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20141017200330/http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr to http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr#47:1.0.1.1.16.3.234.31

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 16:28, 1 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on List of WLAN channels. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit User:Cyberpower678/FaQs#InternetArchiveBot*this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.mityc.es/Telecomunicaciones/Secciones/Espectro/cnaf/
• Added archive https://web.archive.org/web/20141017200330/http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr#47:1.0.1.1.16.3.234.31 to http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr#47:1.0.1.1.16.3.234.31

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 03:57, 6 June 2016 (UTC)

What is DFS?

What is DFS? That and a number of other abbreviations are not defined in the page - essential for an encyclopedia. — Preceding unsigned comment added by 129.192.208.15 (talk) 03:23, 10 November 2016 (UTC)

Channel allocation schemes#DFS --Voidvector (talk) 03:14, 5 December 2019 (UTC)

NonOverlappingChannels2.4GHzWLAN-en.svg

Most of the world might include europe, but in most of europe, the suggested non-overlapping channels are 1, 7 and 13. (or, 1, 3, 5, 7, 9, 11, 13 as half-overlapping channels) 2001:A62:1180:B4F1:88B2:ADCB:ADA9:EDDF (talk) 21:38, 29 January 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on List of WLAN channels. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140201183444/http://rra.go.kr/board/law/view.jsp?lw_seq=187&lw_type=3 to https://rra.go.kr/board/law/view.jsp?lw_seq=187&lw_type=3
• Added {{dead link}} tag to ftp://140.118.9.75/yhl/mobile12/802.11p-intro.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 03:16, 28 December 2017 (UTC)

Out of date 5 GHz section for South Africa

The information for South Africa under the "5 GHz" section is out of date. The reference to regulations given is accurate, but from 2008. The 2015 regulations state that many of the channels marked as in the table as "No", specifically those in the 5.725-5.875 GHz range, are now reserved for applications like WAS, RLAN, BFWA and RTTT data..

References

Indoorness/availability of 5690–5730, 5710–5730, 5735–5815

Dear editor. I have reverted your deletions, but you are free to explain why we would need to make the changes you have proposed. I have double checked the existing references and could not spot on error at first, but do correct me if you have additional references. bkil (talk) 17:10, 8 July 2018 (UTC)

Reformat table

Some of the channels in https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(802.11a/h/j/n/ac/ax) are actually multiple channels bonded together. It would be much clearer if this were signified using more columns with rowspans to combine them. Does this affect the regulatory columns? I would think that if channel 5 includes 1,2,3,4, and channel 1 is banned in a place, while channels 2 3 4 are allowed, then channel 5 is implicitly banned, too, since it contains channel 1? Or maybe the channel to frequency table could be separate from the regulatory table? — Omegatron (talk) 23:11, 31 July 2018 (UTC)

I guess there are some weird cases, like 34 and 38 overlapping, or 54 being illegal in EU while its sub-bands 52 and 56 are somewhat legal.  :/ — Omegatron (talk) 23:40, 31 July 2018 (UTC)

Well, here's my attempt, anyway:

160	80	40	20	10	flo	fhi
			184	183	4910	4920
				185	4920	4930
			188	187	4930	4940
				189	4940	4950
			192		4950	4970
			196		4970	4990
			8	7	5030	5040
				9	5040	5050
			12	11	5050	5060
				—	5060	5070
			16		5070	5090
		34	32		5150	5170
50	42		36		5170	5190
		38
			40		5190	5210
		46	44		5210	5230
			48		5230	5250
	58	54	52		5250	5270
			56		5270	5290
		62	60		5290	5310
			64		5310	5330
			68		5330	5350
			96		5470	5490
114	106	102	100		5490	5510
			104		5510	5530
		110	108		5530	5550
			112		5550	5570
	122	118	116		5570	5590
			120		5590	5610
		126	124		5610	5630
			128		5630	5650
	138	134	132		5650	5670
			136		5670	5690
		142	140		5690	5710
			144		5710	5730
	155	151	149		5735	5755
			153		5755	5775
		159	157		5775	5795
			161		5795	5815
			165		5815	5835
			169		5835	5855
			173		5855	5875

— Omegatron (talk) 00:03, 1 August 2018 (UTC)

Yes, something roughly like that looks good.

The standards organisation connect the channel name to the center frequency. So if you bond two 20Mhz channels at 32 and 36, then the new 40Mhz channel is at the average 34. If you stick to the standards, the naming is unique, and you can tell the channel width just from the center frequency/name.

However, there's a problem with that, if channel 32 and channel 44 are in use you can't avoid interference and bond 36 and 40 to form a 40Mhz channel on channel 38, because channel 38 refers to the bonded 80 Mhz channel going from 32-44. So the standards are somewhat inflexible, they're always binary. But I notice that next door's router will nevertheless quite happily bond 36 and 40 anyway, even though that's not apparently a legal bonding.

I don't think bonding 36 and 40 is allowed in the current standards, but there's a possibility that it may be in future. That would make it particularly hard to diagram. Still, we work with what we have in the standards I guess, and come up with something clever if it changes. GliderMaven (talk) 17:16, 29 December 2018 (UTC)

That looks reasonable, but it repeats the "in between" frequency - once as the upper limit, then again on the next line as the lower limit.

I've made an experimental version that avoids this; what do you think? Martin Kealey (talk) 15:24, 20 March 2024 (UTC)

— Viniciustinti (talk) 10:23, 27 March 2019 (UTC)

I would like to propose a caption for explaining Yes, Indoors, DFS and so one. — Preceding unsigned comment added by Viniciustinti (talk • contribs) 27 mrt 2019 11:27 (UTC)

5GHz channels - Linux kernel regulatory database

For those ever looking to update 5GHz channel, here is the link to its text format as "regulatory database" implemented in Linux Kernel: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt?id=HEAD It is pretty close to source of truth, and contain URL in comments of actual source of truth (regulator publications). --Voidvector (talk) Preceding comment added on 5 dec 2019 05:46‎ (UTC)

Should the 2.4GHz channel 12 and 13 in the USA need updating?

I quote the following note from the main article that I would like to discuss with you:

In the US, 802.11 operation on channels 12 and 13 is allowed under low power conditions. The 2.4 GHz Part 15 band in the US allows spread-spectrum operation as long as the 50 dB bandwidth of the signal is within the range of 2,400–2,483.5 MHz62 which fully encompasses both channels 12 and 13. A Federal Communications Commission (FCC) document clarifies that only channel 14 is forbidden and that low-power transmitters with low-gain antennas may operate legally in channels 12 and 13.63 Channels 12 and 13, however, are not normally used in order to avoid any potential interference in the adjacent restricted frequency band, 2,483.5–2,500 MHz,64 which is subject to strict emission limits set out in 47 CFR § 15.205.65 Per recent FCC Order 16-181, "an authorized access point device can only operate in the 2483.5–2495 MHz band when it is operating under the control of a Globalstar Network Operating Center and that a client device can only operate in the 2483.5–2495 MHz band when it is operating under the control of an authorized access point"66

I have the following issues:

• I tried to review the current USA situation in more depth. Could someone please help me calculate the exact limits that we must obey? I tried to piece together the various rules, but I failed to come to the conclusion that transmission is allowed on 1-11 and only on those channels. See the below issues.
• I don't think that the Globalstar comment is relevant at the end - we aren't "operating" within 2483.5-2495MHz when we use 12 or 13, it's only a question of unwanted emissions escaping (I'll address this below). Maybe it's only relevant for channel 14.
• In reference 66 from 2016, comments 33-36 on page 17-18 deal with the question of "opening up" channel 12 and 13. They conclude with "No satisfactory mechanism allowing general use of Channels 12 and 13 in the 2473-2483.5 MHz spectrum without significant risk of interference to Globalstar’s licensed MSS operations has been proposed. Therefore, we decline to relax the restricted band requirements" Is Globalstar on this band still a thing, are there any follow ups about this question from the past few years?
• Commenting on the quote from reference 62: The center frequency channel 11 lies 21.5MHz away from the boundary 2483.5MHz. According to the 802.11b standard spectral mask, 21.5MHz deviation only calls for a power spectral density reduction of 30 dBr (>= 22MHz deviation is needed for 50dBr). So if we needed to obey this rule, only 1-10 would be specifically usable.
• From reference 64 47 CFR § 15.205 "only spurious emissions are permitted in any of the frequency bands listed below: [...] 2483.5-2500". According to §15.209, "the emissions from an intentional radiator shall not exceed the field strength levels specified in the following table:", limiting 2.4GHz band emissions to a maximum of 500 microvolts/meter at a measurement distance of 3 meters.
• The text in Wikipedia also mentions that low power emissinos may be possible on channel 12 and 13, but how low is this, 100mW, 10mW? Anyway, how common is this? Has anybody tried, measured and published anything about this? If this would be a thing, I think we should update wireless-regdb to this effect. If not, we should give a proper link and citation next to the prohibition.
• Considering the equation E = sqrt(30 * P) / r, 500uV/m in the restricted band allows a maximal power of about -41dBm there. As the 802.11 spectral masks only call for a maximum reduction of 50dBr, this couldn't theoretically be met on any of the channels at 1W transmit power. Considering real life systems, according to some spectrum analyzer screenshots I found, this is pretty hard to meet even for channel 11 - do note if you find anything that shows otherwise. On these screenshots it does show that common systems perform vastly better than what the spectral masks call for (much steeper), but they have a pretty long tail (meaning that after a few MHz, distance doesn't matter that much).
• Now if we assumed that routers contained special extra filtering for just above channel 11 (so it rolls off sufficiently before 2483.5MHz), wouldn't that greatly reduce performance on channel 11 and 12 if the device was used in other countries? Or perhaps could this filtering be switched by software (please show me the driver code that does this if yes)? If this extra filtering couldn't be switched, but it still wouldn't hamper channel 11 and 12 operation in other countries, doesn't that mean that if the device passed FCC conformance testing, then the filters could also do their magic in the USA as well?
• Also, if perhaps the signal shape of 802.11g/n transmissions occupy less bandwidth and roll off earlier, would it be perhaps more realistic to only ban 802.11b transmissions on channel 12/13?

--bkil (talk) 19:53, 3 September 2020 (UTC)

The Linux kernel Wireless Regulatory Database (see link above) has been updated on 29 Apr 2020 to allow 30dBm (1 Watt) for the range 2400 - 2483.5MHz in the US. It is considered an authoritative source as it is incorporated into all linux-based Wi-Fi devices. It links to Federal Regulations §15.247 (b) 3, quote: "For systems using digital modulation in the 902-928 MHz, 2400-2483.5 MHz, and 5725-5850 MHz bands: 1 Watt." 89.139.221.165 (talk) 17:19, 30 September 2020 (UTC)

Yes, if you check the git log, you can see that I was the one who sent that update, but I would like to double check with you guys what you think, because you may better know the history regarding channel 12 and 13 in the USA. So the original footnote on the Wikipedia article page tried to reason that disallowing operation on channel 12 and 13 could minimize interference with a potential future commercial service on the nearby band (that seems to have been cancelled since then). -bkil (talk) 17:52, 30 September 2020 (UTC)

Upon further examination, it appears the linux kernel regulatory database is incorrect in allowing 1 Watt on channels 12-13. According to FCC decision from 2016 FCC-16-181A1.pdf, paragraph 36, quote: "No satisfactory mechanism allowing general use of Channels 12 and 13 in the 2473-2483.5 MHz spectrum without significant risk of interference to Globalstar’s licensed MSS operations has been proposed. Therefore, we decline to relax the restricted band requirements because unlicensed operators using channels 12 and 13 would not be able to coordinate with Globalstar to prevent interference with MSS operations above 2483.5 MHz. " Is there any later FCC decision that supersedes this 2016 decision? 89.139.221.165 (talk) 12:01, 5 October 2020 (UTC)

That's a good question. Yes, I've checked that citation before (as I did read all other referenced documents for that section), but all seems to be from long ago. Not sure about the exact relevance, but Globalstar's satellite service didn't seem to have materialized (other than in the S-band and L-band), this would be sketchy since launching Starlink and Kuiper Systems (and this few MHz of bandwidth would have been too little for a global space based broadband network anyway). By the way, if Globalstar really wanted to create a global space network, why did only FCC investigate this question - shouldn't the rest of the world needed to also agree to reduce channel 12 & 13 transmission power (good luck with that)? Now after further reading, it seems that they are just starting to roll out LTE in band 53 (2483.5-2495 MHz), but that's terrestrial use and should be much less noise sensitive compared to satellite based transmissions, so the question still stands. So if anybody knows of any calculation or general recommendation about transmission powers on channel 12 and 13, it would be great to know and/or mention. Until then, I'm closing down channel 12 & channel 13 completely, but I preferred if we could enable them even at low power (like even 10-100mW - most phones aren't capable of much more than 100mW anyway), but someone would need to step up and provide references about tests or calculations to support this.

Also, I've checked this article's history to see if we could discuss the matter with the original author of this footnote about the restriction, but they don't seem to have registered an account and haven't made an edit since then, so they probably aren't available for comment. The edit was made on 2009-07-30. -bkil (talk) 13:17, 5 October 2020 (UTC)

I've inspected some graphs that supposedly depict real world spectral measurements on page 35 and 77 of https://www.rohde-schwarz.com/cz/file/1MA69_2e.pdf. It seems that 50dBr for typical OFDM is just within +/-11.5MHz of the central frequency, hence if this would be the only criterion, channel 13 should also be fine. Although 50dBr for typical CCK seems to need a bit more, about +/- 13.5MHz, so legacy-b operation should probably be safe on channel 12 on paper but needs to be reduced to about 4dBm on channel 13. As a funny fact, if we only based our conclusions on the lax standard spectral mask requirements for CCK that command for +/-22MHz to reach 50dBr, operation would be prohibited above channel 10 (then look at OFDM...). -bkil (talk) 20:27, 13 October 2020 (UTC)

One could try the Wireless Waveform Generator from MatLab. It has better documentation like about OFDM symbols:

"A negative side effect of using an IFFT to process OFDM symbols is the resulting symbol-edge discontinuities. These discontinuities cause out-of-band emissions in the transition region between consecutive OFDM symbols. To smooth the discontinuity between symbols and reduce the intersymbol out-of-band emissions, you can use the wlanWaveformGenerator function to apply OFDM symbol windowing."

From FCC Federal Register :: Table of Frequency Allocations and Radio Regulations "prevent harmful interference to the radio astronomy service from emissions in the 2483.5-2500 MHz band, especially those caused by second-harmonic radiation that would fall into the 4990-5000 MHz band allocated to the radio astronomy service worldwide."

This second-harmonic arguments helps but it also points to use 5GHz minimum power rules or other that apply +4990MHz one can find.

Then 000179106.pdf (soumu.go.jp) cites for safety in the mentioned 4990 band to restrict "10 mW/MHz in any 1 MHz band" . But further explains why lower eirp by 3dBm if one dos not have TPC.

One of the conversion formulas used to compare power the regulation:

" −124 − 20 log10 (hSAT/1 414) dB(W/(m2 · 1 MHz)), or equivalently,

−140 − 20 log10 (hSAT/1 414) dB(W/(m2 · 25 kHz)), at the FSS satellite orbit, where hSAT is the altitude of the satellite (km)."

The ealier FCC doc also gives −159 dB (W/(m2 · 4 kHz) as limit around 2483.5MHz.

But from comparing the intent of limiting power density the safest value I could find:

"In addition, the maximum power spectral density shall not exceed 11 dBm in any 1 megahertz band."

Or my proposal of using "TPC rules" to a safer lower 4 ~ 6dBm;

In terms of allocation the new FCC table actually makes me doubt how Wifi use is really defined between 2417 to 2450.

Anyway thanks for anyone trying to parse this but i think its rules are relevant even for other 5, 6, GHz greater bands. 2804:30C:1B0C:8100:1D5:6F60:54E9:ADB6 (talk) 02:15, 17 August 2024 (UTC)

Following is a footnote on WifiAlliance paper on spectrum usage for 5/6GHz :

[24] LPI or ‘Low-power (indoor)’ operation implies the use of a maximum 5dBm/MHz eirp, rather than the 36dBm (absolute) eirp permitted for ‘Standard Power’ operation. This gives 27 dBm for a 160 MHz channel, 30 dBm for 320 MHz (reaches absolute limit at 1260 MHz bandwidth.

using the above rule 20MHz indoor channel 12/13 LowPowerIndoor max at 18 dBm. 2804:30C:1B09:1300:DC69:617D:EAB6:70A5 (talk) 00:58, 24 August 2024 (UTC)

6 GHz adopted in European Union

Linked from this wi-fi.org page, I found that the EU has adopted the lower end of the 6 GHz range. Can someone update the article accordingly? -- 2A00:23C7:8913:6101:D4AD:679D:4117:BDE2 (talk) 18:52, 9 October 2021 (UTC)

dara

via 197.156.77.136 (talk) 17:38, 8 January 2022 (UTC)

802.11ax is not a frequency but rather a protocol

Many routers use the 802.11ax protocol on their 2.4GHz and 5GHz bands. Many incorrect references using this misinformation are present in this article.

Please correct this misinformation. 802.11ax is not related the 6GHz only.142.113.109.188 (talk) 12:31, 24 June 2022 (UTC)

Hola

Como saco la contraseña del wifi ? 186.12.28.54 (talk) 13:03, 25 July 2022 (UTC)

Jonatan 181.9.187.85 (talk) 11:25, 18 April 2024 (UTC)

Channel 144 in Europe

In Europe, we do have ETSI 301 893 that defines the frequency range of 5150 - 5350 MHz (with up to 200 mW of transmit power (e.i.r.p.)) and 5470 - 5725 MHz (with up to 1000 mW of transmit power (e.i.r.p.)) for unlicensed devices like Wi-Fi.

Furthermore, we do have ETSI 300 440 for Short Range Devices (SRD), which includes Wi-Fi for certain frequency ranges, defining the frequency range for 5725 - 5875 MHz with up to 25 mW of transmit power (e.i.r.p.). As channel 144 is defined for 5710 - 5730 MHz, this channel is somehow in-between those to harmonised standards. With the given ruling, I do not see how this channel could be allowed to be used with either ETSI 301 893 or ETSI 300 440. Therefore, please edit the frequency table accordingly including the 40/80 MHz channels 142 and 138.

PS: The ruling seems to be different in UK, which is entitled to have different rules than ETSI. Pebbecke (talk) 10:23, 1 June 2023 (UTC)

I noticed that anomaly when I was compacting the table to use rowspans, but I didn't know enough to fix it at the time.

Looking again, it's obvious that channel 140 prohibiting SRD (25 mW ERP) over 5690–5710 MHz is incompatible with SRD operation being permitting by both channel 142 (5690–5730 MHz) and channel 138 (5650–5730 MHz).

At minimum the descriptions of channels 138 & 140 should be swapped, which that would imply that SRD operation is permissible over 5690–5815 MHz.

But from your description, it seems like no part of 5650–5725 MHz should be used for ERP SRD, so the description for channels 96-136 should be extended to cover channels 138-148 as well.

Which way should it be fixed? Martin Kealey (talk) 04:09, 17 July 2023 (UTC)

Hi Martin,

due to my vacation, this reply is rather late.

I'm sorry, but I do not really understand the options that you give me and the part "part of 5650–5725 MHz should be used for ERP" confuses me. I propose to limit SRD in Europe to channels > 144 as an SRD device usually does not detect any radars, which is required to operate on channels 100-140. 95.223.45.155 (talk) 17:07, 31 July 2023 (UTC)

"no part of" = "none of" Martin Kealey (talk) 08:51, 6 November 2023 (UTC)

My confusion is more about the term "ERP". :-) Anyway, I propose to remove the SRD part from channel 144 for Europe and replace it with a "No" with a red background. The first channel that can then use SRD ruling in Europe is 149. Is that a good way forward? Pebbecke (talk) 12:40, 6 November 2023 (UTC)

Thinking about this more broadly, it's always legal to transmit with less than the maximum allowed power. Which means (a) I was confused when I talked about prohibiting SRD, and (b) your suggested fix is actually backwards.

In particular, it's legal to transmit with 25 mW on any frequency between 5150 and 5875 MHz, but

• between 5150 and 5725 MHz you may increase the power output to 200 mW; and
• between 5470 and 5725 MHz you may further increase the power output to 1 W.

The implication is that you cannot use channels 144, 142 or 138 at the 1 W level because they exceed the upper frequency limit of 5725 MHz. Unfortunately that means the current table is technically correct, though somewhat unintuitive. Martin Kealey (talk) 14:40, 15 November 2023 (UTC)

Hi Martin,

where do you get the impression that it is legal to transmit in the ETSI region with 25 mW between 5150 and 5875 MHz? I would like to see your source for that. AFAIK, ETSI always requires DFS for certain ranges within the 5 GHz spectrum and the SRD rules do not require any DFS implementation. My sources are ETSI 300 440 v2.2.1 with the transmit power table under 4.2.2.4, entry #5. What is your source? Pebbecke (talk) 20:28, 19 November 2023 (UTC)

I'm looking at the same document. DFS (frequency hopping) is orthogonal to power level.

Martin Kealey (talk) 15:27, 23 November 2023 (UTC)

The document EN 301 893 does remove devices from the DFS implementation requirement if they are slave devices (I assume you are referring to Table D.2 note 2), but that also means that there is a master device that needs to do DFS (for them) and that master will also set the maximum, supported bandwidth for the slave devices. Do you have any other clause/table that removes even a master device from DFS implementation?

By now it would be great to grab a drink together and discuss this further. :-) Pebbecke (talk) 19:37, 27 November 2023 (UTC)

We seem to be talking at cross purposes.

I'm not saying that DFS does not apply; on the contrary, I'm saying that it is permissible to transmit in channels 144, 142, and 138 only if you comply with both DFS and SRD requirements: choose channels that will minimise interference and stay under 25 mW. (This is similar to how channels marked "DFS/TPC" mean you must comply with both rules to use those channels.)

(SRD and TPC are both about power limits; SRD is more stringent, so it's safe to ignore TPC where SRD applies.)

Technically SRD's 25 mW power limit only applies to the upper half of channel 144, so the aggregate limit would be 50 mW for channel 144, 100 mW for channel 142, and 200 mW for channel 138, assuming you have a uniform spectral power.

Conversely, I don't think you need to use DFS for just channel 144. However it isn't forbidden to do so, and it may simplify the implementation.

On a separate note, since radar avoidance doesn't apply to these channels; they should probably be labelled just "DFS" rather than "DFS/TPC".

That drink sounds like a great idea.!

Martin Kealey (talk) 05:22, 28 November 2023 (UTC)

Sounds like we are now on the same track and share the same view on the regulation and how it could be possible to operate on those channels. So yes, you would need to make sure that you have DFS functionality and comply with the much lower SRD power limit for the last 5 MHz covered by SRD ruling by reducing the ERP of the full 20 MHz channel.

I am still not sure if it is possible to certify a Wi-Fi device operating on channel 144 (or the 40/80 MHz combinations including 144, namely 138 or 142 by combining two different ETSI norms. That would be a great question for a regulator or a test lab as this detail is beyond my expertise. Usually, you do testing according to one ETSI EN at a time and prove your compliance within the defined frequency range of the norm. Pebbecke (talk) 17:01, 1 December 2023 (UTC)

How does it look now?

The whole thing is confusing; ETSI EN 301 893 says that the intention is to harmonize, but in doing so they chop off 5725 to 5730 MHz from channels 138, 142, 144 and 145; it seems like a mistake in the ECC specification.

Martin Kealey (talk) — Preceding undated comment added 15:46, 15 November 2023 (UTC)

(untitled section by anonymous user)

Depiction of a Wi-Fi network in infrastructure mode. The device sends information wirelessly to another device, both connected to the local network, to print a document. 134.35.253.201 (talk) 18:09, 23 August 2023 (UTC)

Tabulation of 5.9 GHz in 802.11p

Request for Feedback

An update on 10 June 2023 created a new table spanning 5855~5990 MHz within the section titled "5.9 GHz (802.11p)".

This new table overlaps and conflicts with the tables in both the 5 GHz and 6 GHz sections, by spanning 5855~5895 MHz and 5935~5990 MHz respectively.

I am concerned about the accuracy and currency of the material inserted by this update.

It lacks citations, other than the 802.11p article, and appears to have even misinterpreted that source. For example, it says "No" for the section where the US removed the restriction on the bottom 45 MHz of this band, meaning it went from being available only to licensed users, to effectively being an extension of the existing "5 GHz" unlicensed band. Moreover, this unlicensed access was already shown in the table in the 5 GHz section.

Although 802.11p is based on WiFi, it differs in some technical as well as legal aspects. It's the technology underpinning V2X and WAVE which are licensed uses of the spectrum, and not available to consumer-grade WiFi devices at all.

Even if the rest of the information was accurate (which I now doubt), it is questionable whether this section as a whole is relevant to this article: although it's not explicitly stated, the rest of this article is about use of the radio spectrum by unlicensed WiFi devices; as far as such devices are concerned, the portions marked in green in this table are not usable.

Depending on how you view the overall focus of the article, this is either misleading, or outright wrong.

Accordingly, I propose to:

1. remove the table, after inserting any relevant portions into the existing 5 GHz and 6 GHz tables.
   • At this point I suspect there is no salvageable information, but I would appreciate feedback on this.
2. remove "5.9 GHz" from the section title, leaving just "802.11p", and demoted it to a sub-heading within the 5 GHz section. Amend the following text to highlight that licensed spectrum use is outside the scope of this article. The only relevant point is that this block has been halved in size, thus expanding the
3. add a note to the article preamble to point out that it's about unlicensed spectrum use

Martin Kealey (talk) 12:30, 28 November 2023 (UTC)

Channel number for 5935 MHz

First problem: in the "6 GHz" section, the channel centred on 5935 MHz is labelled as "2", while the channel centred on 5945 MHz is labelled as "1". Is this anomalous ordering real, or a wiki editing error at some point?

Second problem: in the "5.9GHz (809.11p)" section, the same channel centred on 5935 MHz is labelled as "187". This follows the logical numbering of channels starting with channel 1 centred on 5005 MHz in the "5 GHz" section above that.

(As a side note, designating "5 GHz" and "6 GHz" as "separate bands" seems unjustified to me; the U-NII-2B radar protection gap is 120 MHz wide within the "5 GHz band", while the gap between the "5 GHz band" and the "6 GHz band" is only 50 MHz. Used this way the term "band" is at once both too coarse and too fine.) Martin Kealey (talk) 12:57, 28 November 2023 (UTC)

Poor quality references

After noting that some points seem rather dubious, despite being supported by citations, I've been trying to follow those citations to see what they really say.

This is a can of worms. Many of the citations simply refer to an entire act or regulation, often hundreds of pages, without noting any kind of internal anchor such as a section title or number, page number, or similar. This makes them worse than useless.

For example,

in footnote B of the 2.4 GHz section, the sentence "The 2.4 GHz Part 15 band in the US allows … channels 1 through 13" includes a reference, which only says:

• "dead link"➚. Archived from the original➚ on 2012-12-12. Retrieved 18 February 2014.

with two links:

• A. https://archive.today/20121212090129/http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47:1.0.1.1.16;idno=47;cc=ecfr%2347:1.0.1.1.16.3.234.31
• B. https://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c%3Decfr%3Bsid%3D9eab2402bb1cccc8f85bb3fa9e6c2daa%3Brgn%3Ddiv5%3Bview%3Dtext%3Bnode%3D47%3A1.0.1.1.16%3Bidno%3D47%3Bcc%3Decfr#47:1.0.1.1.16.3.234.31

In case you're wondering how the archive URL can be shorter than the original, that's because the original is "over encoded", and should look like this:

• C. https://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47:1.0.1.1.16;idno=47;cc=ecfr#47:1.0.1.1.16.3.234.31

The whole "archive.today" site is broken, as it's "protected" by a faulty captcha, so I trying searching on archive.org instead.

I found a single backup of the original (archived on 17 Oct 2014)

• D. https://web.archive.org/web/20141017200330/https://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47:1.0.1.1.16;idno=47;cc=ecfr#47:1.0.1.1.16.3.234.31

when it was a redirection to

• E. http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr

which likewise has only a single backup (archived on the same day)

• F. https://web.archive.org/web/20141020231024/http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr

Link E currently says:

Please update your bookmark to: https://www.ecfr.gov/current/title-47/part-15

Additional details for the administrator of the site you came from: The link https://www.ecfr.gov/cgi-bin/text-idx?c=ecfr;sid=9eab2402bb1cccc8f85bb3fa9e6c2daa;rgn=div5;view=text;node=47%3A1.0.1.1.16;idno=47;cc=ecfr is no longer valid and should be replaced with https://www.ecfr.gov/current/title-47/part-15

Critically, the original anchor #47:1.0.1.1.16.3.234.31 no longer works even if appended manually; the current site wraps each section in a div tag with an id= anchor that matches the legislative naming convention, like #p-15.3(a)(1).

This means one is faced with trying to find the intended referent among about 375000 visible letters and symbols (not counting space, line breaks, or any hypertext markup) or about 2300 paragraphs (and headings, bullet points, footnotes, etc).

This is by no means the only reference which fails to use sufficient precision; the overwhelming majority of reference descriptions simply name entire documents with no further information, and almost as many reference hyperlinks lack anchors or other section indicators.

In most countries, legislation has "stable" section and paragraph numbering (repealing or inserting paragraphs does not change the numbering of other paragraphs), so legal citations should always display the specific paragraph number, and include an equivalent anchor in the hyperlink.

Please if you add a new citation, include sufficient precision that it does not take hours of searching to find what you're referring to. Martin Kealey (talk) 15:53, 4 December 2023 (UTC)

@Martin Kealey I found the relevant section of Part 15, it's § 15.249. (Leaving this note, as I found it when I really need to get to sleep. I'll correct that cite tomorrow if I remember) AtomicSource (talk) 16:05, 29 August 2024 (UTC)

@AtomicSource thankyou for sorting that reference. I do appreciate it, but I remain frustrated that so many other references lack sufficient precision to be useful. Martin Kealey (talk) 09:15, 19 September 2024 (UTC)

Como puedo decifrar la contraseñas de mi wifi

190.123.10.90 (talk) 07:59, 23 February 2024 (UTC)

Es me sa 190.123.10.90 (talk) 08:00, 23 February 2024 (UTC)

SOSB12 201.162.240.87 (talk) 10:45, 6 March 2024 (UTC)

— Preceding unsigned comment added by 200.52.203.42 (talk) 14:56, 11 November 2023 (UTC)

@ 1.47.194.51 (talk) 08:20, 6 March 2024 (UTC)

junaid 2001:8F8:1DB6:118B:51E7:C871:BDA3:4588 (talk) 17:18, 11 March 2024 (UTC)

---

"How do I decrypt my wifi passwords?"

There are two possible interpretations of this:

• Decrypting the stored passwords in your device.
• Obtaining the password for a SSID where you've lost it.

WiFi encryption is designed to make it infeasible to decrypt transmissions. Some older weaker encryption systems can now be broken if you have enough resources, but newer ones cannot.

So in both cases you would need administrative access to the device. Typically phones do not allow anyone to decrypt the password store. WiFi routers on the other hand will simply display the password to anyone logging in with the admin password.

Martin Kealey (talk) 10:40, 21 April 2024 (UTC)

El capo 201.242.156.134 (talk) 20:21, 13 October 2024 (UTC)

Revision as of 09:02,28 may 2024

It's False positive Sahib22 (talk) 10:56, 28 May 2024 (UTC)

M 139.47.0.240 (talk) 16:35, 31 May 2024 (UTC)

Buenavista bacon district Sorsogon City

this place is more in wifi 14.1.65.120 (talk) 12:28, 28 September 2024 (UTC)

Changing my password

Changing the password 2606:3C80:8C00:3E8:E970:44D4:EAA6:B692 (talk) 20:25, 7 November 2024 (UTC)