* Tx power for slave devices in ETSI DFS region @ 2018-12-11 2:30 ` Igor Mitsyanko 0 siblings, 0 replies; 10+ messages in thread From: Igor Mitsyanko @ 2018-12-11 2:30 UTC (permalink / raw) To: wireless-regdb; +Cc: linux-wireless Hello, according to ETSI https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf section 4.2.3.2.2, table 2 Note 3 states: >Slave devices without a Radar Interference Detection function shall >comply with the limits for the frequency range 5 250 MHz to 5 350 MHz. And Tx power limits are defined as following: 5150 to 5350: 20 dbm 5470 to 5725: 27 dbm Which means that if STA device can not do radar detection, it must use 20dbm Tx powers on all channels (can not use 27 dbm limit). Looking at regdb https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt, power limit for frequency range 5470 to 5725 is defined at 27 dbm. Question is: does wireless core assumes that each device can do radar detection in slave modes (eg acting as a STA) and it is enabled by default? I couldn't find any logic in kernel which would limit 27 dbm power to 20 for STA devices. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [wireless-regdb] Tx power for slave devices in ETSI DFS region @ 2018-12-11 2:30 ` Igor Mitsyanko 0 siblings, 0 replies; 10+ messages in thread From: Igor Mitsyanko @ 2018-12-11 2:30 UTC (permalink / raw) To: wireless-regdb; +Cc: linux-wireless Hello, according to ETSI https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf section 4.2.3.2.2, table 2 Note 3 states: >Slave devices without a Radar Interference Detection function shall >comply with the limits for the frequency range 5 250 MHz to 5 350 MHz. And Tx power limits are defined as following: 5150 to 5350: 20 dbm 5470 to 5725: 27 dbm Which means that if STA device can not do radar detection, it must use 20dbm Tx powers on all channels (can not use 27 dbm limit). Looking at regdb https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt, power limit for frequency range 5470 to 5725 is defined at 27 dbm. Question is: does wireless core assumes that each device can do radar detection in slave modes (eg acting as a STA) and it is enabled by default? I couldn't find any logic in kernel which would limit 27 dbm power to 20 for STA devices. _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx power for slave devices in ETSI DFS region 2018-12-11 2:30 ` [wireless-regdb] " Igor Mitsyanko @ 2019-01-15 13:45 ` Johannes Berg -1 siblings, 0 replies; 10+ messages in thread From: Johannes Berg @ 2019-01-15 13:45 UTC (permalink / raw) To: Igor Mitsyanko, wireless-regdb; +Cc: linux-wireless Hi Igor, On Tue, 2018-12-11 at 02:30 +0000, Igor Mitsyanko wrote: > Hello, > > according to ETSI > https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf > section 4.2.3.2.2, table 2 > Note 3 states: > >Slave devices without a Radar Interference Detection function shall > >comply with the limits for the frequency range 5 250 MHz to 5 350 MHz. > > And Tx power limits are defined as following: > 5150 to 5350: 20 dbm > 5470 to 5725: 27 dbm > Which means that if STA device can not do radar detection, it must use > 20dbm Tx powers on all channels (can not use 27 dbm limit). > > > Looking at regdb > https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt, > power limit for frequency range 5470 to 5725 is defined at 27 dbm. I guess somebody misinterpreted the spec, or some countries are less strict? > Question is: does wireless core assumes that each device can do radar > detection in slave modes (eg acting as a STA) and it is enabled by > default? I couldn't find any logic in kernel which would limit 27 dbm > power to 20 for STA devices. No, we shouldn't assume that it can do radar detection by itself ... I guess we should have some code? Or just fix the regdb? johannes ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region @ 2019-01-15 13:45 ` Johannes Berg 0 siblings, 0 replies; 10+ messages in thread From: Johannes Berg @ 2019-01-15 13:45 UTC (permalink / raw) To: Igor Mitsyanko, wireless-regdb; +Cc: linux-wireless Hi Igor, On Tue, 2018-12-11 at 02:30 +0000, Igor Mitsyanko wrote: > Hello, > > according to ETSI > https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/en_301893v020101p.pdf > section 4.2.3.2.2, table 2 > Note 3 states: > >Slave devices without a Radar Interference Detection function shall > >comply with the limits for the frequency range 5 250 MHz to 5 350 MHz. > > And Tx power limits are defined as following: > 5150 to 5350: 20 dbm > 5470 to 5725: 27 dbm > Which means that if STA device can not do radar detection, it must use > 20dbm Tx powers on all channels (can not use 27 dbm limit). > > > Looking at regdb > https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt, > power limit for frequency range 5470 to 5725 is defined at 27 dbm. I guess somebody misinterpreted the spec, or some countries are less strict? > Question is: does wireless core assumes that each device can do radar > detection in slave modes (eg acting as a STA) and it is enabled by > default? I couldn't find any logic in kernel which would limit 27 dbm > power to 20 for STA devices. No, we shouldn't assume that it can do radar detection by itself ... I guess we should have some code? Or just fix the regdb? johannes _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx power for slave devices in ETSI DFS region 2019-01-15 13:45 ` [wireless-regdb] " Johannes Berg @ 2019-01-16 3:58 ` Igor Mitsyanko -1 siblings, 0 replies; 10+ messages in thread From: Igor Mitsyanko @ 2019-01-16 3:58 UTC (permalink / raw) To: Johannes Berg, wireless-regdb; +Cc: linux-wireless On 1/15/19 5:45 AM, Johannes Berg wrote: >> Question is: does wireless core assumes that each device can do radar >> detection in slave modes (eg acting as a STA) and it is enabled by >> default? I couldn't find any logic in kernel which would limit 27 dbm >> power to 20 for STA devices. > > No, we shouldn't assume that it can do radar detection by itself ... > > I guess we should have some code? Or just fix the regdb? > > johannes > > Maybe we have to do both, as there are multiple things to consider: - current regdb values are fine for AP mode - Tx power values can be 3 dbm higher if TPC is supported. This is mentioned in a comment in regdb, but not used anywhere. - if STA detects radar, non-occupancy period must start - when non-occupancy period elapses, STA must do CAC before returning to channel. I guess CAC must be triggered by wpa_supplicant? I'm not sure how to present additional information in regdb while preserving backwards compatibility. Maybe we can: 1. Have a separate rule marked with NO_RDETECT flag which will advertise lower Tx power. Linux wireless core will have to select rule with highest Tx power if possible, for better results. 2. For TPC 3dbm gain, have a flag TPC_GAIN As an example, AW rules will look like: country AW: DFS-ETSI (2402 - 2482 @ 40), (20) (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 Linux wireless core will have to update Tx power values when switching from AP and STA modes, and somehow notify drivers. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region @ 2019-01-16 3:58 ` Igor Mitsyanko 0 siblings, 0 replies; 10+ messages in thread From: Igor Mitsyanko @ 2019-01-16 3:58 UTC (permalink / raw) To: Johannes Berg, wireless-regdb; +Cc: linux-wireless On 1/15/19 5:45 AM, Johannes Berg wrote: >> Question is: does wireless core assumes that each device can do radar >> detection in slave modes (eg acting as a STA) and it is enabled by >> default? I couldn't find any logic in kernel which would limit 27 dbm >> power to 20 for STA devices. > > No, we shouldn't assume that it can do radar detection by itself ... > > I guess we should have some code? Or just fix the regdb? > > johannes > > Maybe we have to do both, as there are multiple things to consider: - current regdb values are fine for AP mode - Tx power values can be 3 dbm higher if TPC is supported. This is mentioned in a comment in regdb, but not used anywhere. - if STA detects radar, non-occupancy period must start - when non-occupancy period elapses, STA must do CAC before returning to channel. I guess CAC must be triggered by wpa_supplicant? I'm not sure how to present additional information in regdb while preserving backwards compatibility. Maybe we can: 1. Have a separate rule marked with NO_RDETECT flag which will advertise lower Tx power. Linux wireless core will have to select rule with highest Tx power if possible, for better results. 2. For TPC 3dbm gain, have a flag TPC_GAIN As an example, AW rules will look like: country AW: DFS-ETSI (2402 - 2482 @ 40), (20) (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 Linux wireless core will have to update Tx power values when switching from AP and STA modes, and somehow notify drivers. _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region 2019-01-16 3:58 ` [wireless-regdb] " Igor Mitsyanko @ 2019-01-16 10:26 ` Petko Bordjukov -1 siblings, 0 replies; 10+ messages in thread From: Petko Bordjukov @ 2019-01-16 10:26 UTC (permalink / raw) To: Igor Mitsyanko; +Cc: Johannes Berg, wireless-regdb, linux-wireless Hello Igor and Johannes, From my research around TPC and radar detection in the context of the BG regulatory domain and respectively ETSI, the relevant regulatory rules are more specific than both what can currently be expressed in the regdb and what will be possible to be expressed with your suggested modifications. For example, in [1] it is stated that for the 5470-5725 MHz band: * The maximum allowed transmission power is 1 W e.i.r.p. with a maximum of 50 mW/MHz spectral density of the average e.i.r.p. for each 1 MHz band. * The use of TPC that ensures lowering the average e.i.r.p. of the entire system (as I understand it, this means both the AP and STAs) of at least 3 dbm is required. * In case TPC (as I understand it -- that exhibits the parameters above) is not used, both the maximum allowed transmission power and maximum spectral density of the average e.i.r.p. are lowered by 3 dB. * The use of methods for limiting radio interference ensuring at least the described in BDS 301 893 (respectively ETSI 301 893) protection for providing coexistance with radio radar systems. If there is will to extend the regdb format to be able to express accurately and in their entirety the specifics of the relevant regulations, IMO a wider and more detailed discussion is in order. [1] http://www.crc.bg/files/_bg/Spisak_2015.pdf - List of radio equipment that uses harmonized within the European Union bands and electronic communications terminal equipment (the List) Best regards, Petko On Wed, Jan 16, 2019 at 6:00 AM Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote: > > On 1/15/19 5:45 AM, Johannes Berg wrote: > >> Question is: does wireless core assumes that each device can do radar > >> detection in slave modes (eg acting as a STA) and it is enabled by > >> default? I couldn't find any logic in kernel which would limit 27 dbm > >> power to 20 for STA devices. > > > > No, we shouldn't assume that it can do radar detection by itself ... > > > > I guess we should have some code? Or just fix the regdb? > > > > johannes > > > > > > Maybe we have to do both, as there are multiple things to consider: > - current regdb values are fine for AP mode > - Tx power values can be 3 dbm higher if TPC is supported. This is > mentioned in a comment in regdb, but not used anywhere. > - if STA detects radar, non-occupancy period must start > - when non-occupancy period elapses, STA must do CAC before returning to > channel. I guess CAC must be triggered by wpa_supplicant? > > > I'm not sure how to present additional information in regdb while > preserving backwards compatibility. Maybe we can: > 1. Have a separate rule marked with NO_RDETECT flag which will advertise > lower Tx power. Linux wireless core will have to select rule with > highest Tx power if possible, for better results. > 2. For TPC 3dbm gain, have a flag TPC_GAIN > As an example, AW rules will look like: > > country AW: DFS-ETSI > (2402 - 2482 @ 40), (20) > (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 > (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 > (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 > (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 > > Linux wireless core will have to update Tx power values when switching > from AP and STA modes, and somehow notify drivers. > _______________________________________________ > wireless-regdb mailing list > wireless-regdb@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region @ 2019-01-16 10:26 ` Petko Bordjukov 0 siblings, 0 replies; 10+ messages in thread From: Petko Bordjukov @ 2019-01-16 10:26 UTC (permalink / raw) To: Igor Mitsyanko; +Cc: linux-wireless, Johannes Berg, wireless-regdb Hello Igor and Johannes, From my research around TPC and radar detection in the context of the BG regulatory domain and respectively ETSI, the relevant regulatory rules are more specific than both what can currently be expressed in the regdb and what will be possible to be expressed with your suggested modifications. For example, in [1] it is stated that for the 5470-5725 MHz band: * The maximum allowed transmission power is 1 W e.i.r.p. with a maximum of 50 mW/MHz spectral density of the average e.i.r.p. for each 1 MHz band. * The use of TPC that ensures lowering the average e.i.r.p. of the entire system (as I understand it, this means both the AP and STAs) of at least 3 dbm is required. * In case TPC (as I understand it -- that exhibits the parameters above) is not used, both the maximum allowed transmission power and maximum spectral density of the average e.i.r.p. are lowered by 3 dB. * The use of methods for limiting radio interference ensuring at least the described in BDS 301 893 (respectively ETSI 301 893) protection for providing coexistance with radio radar systems. If there is will to extend the regdb format to be able to express accurately and in their entirety the specifics of the relevant regulations, IMO a wider and more detailed discussion is in order. [1] http://www.crc.bg/files/_bg/Spisak_2015.pdf - List of radio equipment that uses harmonized within the European Union bands and electronic communications terminal equipment (the List) Best regards, Petko On Wed, Jan 16, 2019 at 6:00 AM Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> wrote: > > On 1/15/19 5:45 AM, Johannes Berg wrote: > >> Question is: does wireless core assumes that each device can do radar > >> detection in slave modes (eg acting as a STA) and it is enabled by > >> default? I couldn't find any logic in kernel which would limit 27 dbm > >> power to 20 for STA devices. > > > > No, we shouldn't assume that it can do radar detection by itself ... > > > > I guess we should have some code? Or just fix the regdb? > > > > johannes > > > > > > Maybe we have to do both, as there are multiple things to consider: > - current regdb values are fine for AP mode > - Tx power values can be 3 dbm higher if TPC is supported. This is > mentioned in a comment in regdb, but not used anywhere. > - if STA detects radar, non-occupancy period must start > - when non-occupancy period elapses, STA must do CAC before returning to > channel. I guess CAC must be triggered by wpa_supplicant? > > > I'm not sure how to present additional information in regdb while > preserving backwards compatibility. Maybe we can: > 1. Have a separate rule marked with NO_RDETECT flag which will advertise > lower Tx power. Linux wireless core will have to select rule with > highest Tx power if possible, for better results. > 2. For TPC 3dbm gain, have a flag TPC_GAIN > As an example, AW rules will look like: > > country AW: DFS-ETSI > (2402 - 2482 @ 40), (20) > (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 > (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 > (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 > (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 > > Linux wireless core will have to update Tx power values when switching > from AP and STA modes, and somehow notify drivers. > _______________________________________________ > wireless-regdb mailing list > wireless-regdb@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/wireless-regdb _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region 2019-01-16 10:26 ` Petko Bordjukov @ 2019-01-16 12:49 ` Bjørn Mork -1 siblings, 0 replies; 10+ messages in thread From: Bjørn Mork @ 2019-01-16 12:49 UTC (permalink / raw) To: Petko Bordjukov Cc: Igor Mitsyanko, linux-wireless, Johannes Berg, wireless-regdb You could simplify the entries for most of the CEPT area by coding in a common reference to the ECC/DEC/(04)08 instead of trying to express every detailed restriction from every national regulation. There is absolutely no reason to make the regulatory database more complicated than what you find in https://www.erodocdb.dk/document/381 and the associated implemetation status on https://www.efis.dk/matrixviewer.jsp?annex=18 The CEPT members can and should be expected to keep the ERO database updated. Duplicating that job is unnecessary and only causes errors. The national regulations are supposed to be implementations of the ECC/DEC/(04)08. Any differences should be explained and documented in the ERO database, or they can be considered translation errors. So there should not be much difference between most of the CEPT countries for the 5150-5350 and 5470-5725 MHz bands, according to the current ECC/DEC/(04)08 implementation status. Just my .02 € Bjørn Petko Bordjukov <bordjukov@gmail.com> writes: > Hello Igor and Johannes, > > From my research around TPC and radar detection in the context of the BG > regulatory domain and respectively ETSI, the relevant regulatory rules are more > specific than both what can currently be expressed in the regdb and what will be > possible to be expressed with your suggested modifications. > > For example, in [1] it is stated that for the 5470-5725 MHz band: > > * The maximum allowed transmission power is 1 W e.i.r.p. with a maximum of 50 > mW/MHz spectral density of the average e.i.r.p. for each 1 MHz band. > > * The use of TPC that ensures lowering the average e.i.r.p. of the entire > system (as I understand it, this means both the AP and STAs) of at least 3 > dbm is required. > > * In case TPC (as I understand it -- that exhibits the parameters above) is > not used, both the maximum allowed transmission power and maximum spectral > density of the average e.i.r.p. are lowered by 3 dB. > > * The use of methods for limiting radio interference ensuring at least the > described in BDS 301 893 (respectively ETSI 301 893) protection > for providing > coexistance with radio radar systems. > > If there is will to extend the regdb format to be able to express accurately and > in their entirety the specifics of the relevant regulations, IMO a wider and > more detailed discussion is in order. > > [1] http://www.crc.bg/files/_bg/Spisak_2015.pdf - List of radio equipment that > uses harmonized within the European Union bands and electronic > communications terminal equipment (the List) > > Best regards, > > Petko > > On Wed, Jan 16, 2019 at 6:00 AM Igor Mitsyanko > <igor.mitsyanko.os@quantenna.com> wrote: >> >> On 1/15/19 5:45 AM, Johannes Berg wrote: >> >> Question is: does wireless core assumes that each device can do radar >> >> detection in slave modes (eg acting as a STA) and it is enabled by >> >> default? I couldn't find any logic in kernel which would limit 27 dbm >> >> power to 20 for STA devices. >> > >> > No, we shouldn't assume that it can do radar detection by itself ... >> > >> > I guess we should have some code? Or just fix the regdb? >> > >> > johannes >> > >> > >> >> Maybe we have to do both, as there are multiple things to consider: >> - current regdb values are fine for AP mode >> - Tx power values can be 3 dbm higher if TPC is supported. This is >> mentioned in a comment in regdb, but not used anywhere. >> - if STA detects radar, non-occupancy period must start >> - when non-occupancy period elapses, STA must do CAC before returning to >> channel. I guess CAC must be triggered by wpa_supplicant? >> >> >> I'm not sure how to present additional information in regdb while >> preserving backwards compatibility. Maybe we can: >> 1. Have a separate rule marked with NO_RDETECT flag which will advertise >> lower Tx power. Linux wireless core will have to select rule with >> highest Tx power if possible, for better results. >> 2. For TPC 3dbm gain, have a flag TPC_GAIN >> As an example, AW rules will look like: >> >> country AW: DFS-ETSI >> (2402 - 2482 @ 40), (20) >> (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 >> (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 >> (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 >> (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 >> >> Linux wireless core will have to update Tx power values when switching >> from AP and STA modes, and somehow notify drivers. >> _______________________________________________ >> wireless-regdb mailing list >> wireless-regdb@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/wireless-regdb > > _______________________________________________ > wireless-regdb mailing list > wireless-regdb@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [wireless-regdb] Tx power for slave devices in ETSI DFS region @ 2019-01-16 12:49 ` Bjørn Mork 0 siblings, 0 replies; 10+ messages in thread From: Bjørn Mork @ 2019-01-16 12:49 UTC (permalink / raw) To: Petko Bordjukov Cc: Igor Mitsyanko, Johannes Berg, linux-wireless, wireless-regdb You could simplify the entries for most of the CEPT area by coding in a common reference to the ECC/DEC/(04)08 instead of trying to express every detailed restriction from every national regulation. There is absolutely no reason to make the regulatory database more complicated than what you find in https://www.erodocdb.dk/document/381 and the associated implemetation status on https://www.efis.dk/matrixviewer.jsp?annex=18 The CEPT members can and should be expected to keep the ERO database updated. Duplicating that job is unnecessary and only causes errors. The national regulations are supposed to be implementations of the ECC/DEC/(04)08. Any differences should be explained and documented in the ERO database, or they can be considered translation errors. So there should not be much difference between most of the CEPT countries for the 5150-5350 and 5470-5725 MHz bands, according to the current ECC/DEC/(04)08 implementation status. Just my .02 € Bjørn Petko Bordjukov <bordjukov@gmail.com> writes: > Hello Igor and Johannes, > > From my research around TPC and radar detection in the context of the BG > regulatory domain and respectively ETSI, the relevant regulatory rules are more > specific than both what can currently be expressed in the regdb and what will be > possible to be expressed with your suggested modifications. > > For example, in [1] it is stated that for the 5470-5725 MHz band: > > * The maximum allowed transmission power is 1 W e.i.r.p. with a maximum of 50 > mW/MHz spectral density of the average e.i.r.p. for each 1 MHz band. > > * The use of TPC that ensures lowering the average e.i.r.p. of the entire > system (as I understand it, this means both the AP and STAs) of at least 3 > dbm is required. > > * In case TPC (as I understand it -- that exhibits the parameters above) is > not used, both the maximum allowed transmission power and maximum spectral > density of the average e.i.r.p. are lowered by 3 dB. > > * The use of methods for limiting radio interference ensuring at least the > described in BDS 301 893 (respectively ETSI 301 893) protection > for providing > coexistance with radio radar systems. > > If there is will to extend the regdb format to be able to express accurately and > in their entirety the specifics of the relevant regulations, IMO a wider and > more detailed discussion is in order. > > [1] http://www.crc.bg/files/_bg/Spisak_2015.pdf - List of radio equipment that > uses harmonized within the European Union bands and electronic > communications terminal equipment (the List) > > Best regards, > > Petko > > On Wed, Jan 16, 2019 at 6:00 AM Igor Mitsyanko > <igor.mitsyanko.os@quantenna.com> wrote: >> >> On 1/15/19 5:45 AM, Johannes Berg wrote: >> >> Question is: does wireless core assumes that each device can do radar >> >> detection in slave modes (eg acting as a STA) and it is enabled by >> >> default? I couldn't find any logic in kernel which would limit 27 dbm >> >> power to 20 for STA devices. >> > >> > No, we shouldn't assume that it can do radar detection by itself ... >> > >> > I guess we should have some code? Or just fix the regdb? >> > >> > johannes >> > >> > >> >> Maybe we have to do both, as there are multiple things to consider: >> - current regdb values are fine for AP mode >> - Tx power values can be 3 dbm higher if TPC is supported. This is >> mentioned in a comment in regdb, but not used anywhere. >> - if STA detects radar, non-occupancy period must start >> - when non-occupancy period elapses, STA must do CAC before returning to >> channel. I guess CAC must be triggered by wpa_supplicant? >> >> >> I'm not sure how to present additional information in regdb while >> preserving backwards compatibility. Maybe we can: >> 1. Have a separate rule marked with NO_RDETECT flag which will advertise >> lower Tx power. Linux wireless core will have to select rule with >> highest Tx power if possible, for better results. >> 2. For TPC 3dbm gain, have a flag TPC_GAIN >> As an example, AW rules will look like: >> >> country AW: DFS-ETSI >> (2402 - 2482 @ 40), (20) >> (5170 - 5250 @ 80), (20), AUTO-BW, TPC_GAIN=3 >> (5250 - 5330 @ 80), (20), DFS, AUTO-BW, TPC_GAIN=3 >> (5490 - 5710 @ 160), (27), DFS, TPC_GAIN=3 >> (5490 - 5710 @ 160), (20), DFS, NO_RDETECT, TPC_GAIN=3 >> >> Linux wireless core will have to update Tx power values when switching >> from AP and STA modes, and somehow notify drivers. >> _______________________________________________ >> wireless-regdb mailing list >> wireless-regdb@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/wireless-regdb > > _______________________________________________ > wireless-regdb mailing list > wireless-regdb@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/wireless-regdb _______________________________________________ wireless-regdb mailing list wireless-regdb@lists.infradead.org http://lists.infradead.org/mailman/listinfo/wireless-regdb ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-01-16 12:50 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-11 2:30 Tx power for slave devices in ETSI DFS region Igor Mitsyanko 2018-12-11 2:30 ` [wireless-regdb] " Igor Mitsyanko 2019-01-15 13:45 ` Johannes Berg 2019-01-15 13:45 ` [wireless-regdb] " Johannes Berg 2019-01-16 3:58 ` Igor Mitsyanko 2019-01-16 3:58 ` [wireless-regdb] " Igor Mitsyanko 2019-01-16 10:26 ` Petko Bordjukov 2019-01-16 10:26 ` Petko Bordjukov 2019-01-16 12:49 ` Bjørn Mork 2019-01-16 12:49 ` Bjørn Mork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.