Japan regulations

Japan regulations

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

The regulatory info for JP looks very odd
(http://wireless.kernel.org/en/developers/Regulatory/Database?alpha2=JP):

country JP:
        (2402.000 - 2472.000 @ 40.000), (N/A, 20.00)
        (2457.000 - 2482.000 @ 20.000), (N/A, 20.00)
        (2474.000 - 2494.000 @ 20.000), (N/A, 20.00), NO-OFDM

        (4910.000 - 4930.000 @ 10.000), (N/A, 23.00)
        (4910.000 - 4990.000 @ 40.000), (N/A, 23.00)

        (4930.000 - 4950.000 @ 10.000), (N/A, 23.00)

        (5030.000 - 5045.000 @ 10.000), (N/A, 23.00)
        (5030.000 - 5090.000 @ 40.000), (N/A, 23.00)
        (5050.000 - 5060.000 @ 10.000), (N/A, 23.00)

        (5170.000 - 5250.000 @ 40.000), (N/A, 20.00)

        (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS

        (5490.000 - 5710.000 @ 40.000), (N/A, 23.00), DFS

multiple of the ranges (blocked) overlap, especially the 4910 MHz part
is strange, seems like that first rule should be killed. Also, how
should the 2.4GHz part be interpreted?

Currently we are not interpreting overlapping ranges properly at all --
we really need to fix a set of interpretation rules.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Japan regulations

[Luis R. Rodriguez]

On Sat, Mar 21, 2009 at 7:39 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> The regulatory info for JP looks very odd
> (http://wireless.kernel.org/en/developers/Regulatory/Database?alpha2=3D=
JP):
>
> country JP:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2402.000 - 2472.000 @ 40.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2457.000 - 2482.000 @ 20.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2474.000 - 2494.000 @ 20.000), (N/A, 20.0=
0), NO-OFDM
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(4910.000 - 4930.000 @ 10.000), (N/A, 23.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(4910.000 - 4990.000 @ 40.000), (N/A, 23.0=
0)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(4930.000 - 4950.000 @ 10.000), (N/A, 23.0=
0)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5030.000 - 5045.000 @ 10.000), (N/A, 23.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5030.000 - 5090.000 @ 40.000), (N/A, 23.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5050.000 - 5060.000 @ 10.000), (N/A, 23.0=
0)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5170.000 - 5250.000 @ 40.000), (N/A, 20.0=
0)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5250.000 - 5330.000 @ 40.000), (N/A, 20.0=
0), DFS
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5490.000 - 5710.000 @ 40.000), (N/A, 23.0=
0), DFS
>
> multiple of the ranges (blocked) overlap, especially the 4910 MHz par=
t
> is strange, seems like that first rule should be killed.

Yeah, I think you're right. The second rule seems to imply the 10 MHz
width part as well.

> Also, how
> should the 2.4GHz part be interpreted?

Channels 1-11 allow 40 width channels, so HT40 is allowed.
Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallowed=
=2E
Channel 14 only allows OFDM.

> Currently we are not interpreting overlapping ranges properly at all =
--
> we really need to fix a set of interpretation rules.

Sort of, we currently stick to the first reg rule which fits our
desired bandwidth. Right now we iterate through 2 possible max
bandwidths -- 40 and 20 and then set the channel max bandwidth based
on which one fits. Note though that we do disregard the freq_range max
bandwidth, which my patches correct.

We also need to consider for future usage custom bandwidths, which I
guess why we had the first JP rule for 4 GHz (but yeah the second rule
seem to imply what the first one intends on allowing). First step
might be to say allow drivers to use monitor mode with 10 MHz
bandwidth or 5 MHz bandwidth. That of course would also need further
work other than regulatory.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Japan regulations

[Gábor Stefanik]

On Sat, Mar 21, 2009 at 8:46 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Channel 14 only allows OFDM.
Only allows CCK, perhaps.


-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: Japan regulations

[Luis R. Rodriguez]

2009/3/21 G=C3=A1bor Stefanik <netrolller.3d@gmail.com>:
> On Sat, Mar 21, 2009 at 8:46 PM, Luis R. Rodriguez <mcgrof@gmail.com>=
 wrote:
>> Channel 14 only allows OFDM.
> Only allows CCK, perhaps.

Heh sorry yeah that, NO-OFDM.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Japan regulations

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

On Sat, 2009-03-21 at 12:46 -0700, Luis R. Rodriguez wrote:

> > country JP:
> >        (2402.000 - 2472.000 @ 40.000), (N/A, 20.00)
> >        (2457.000 - 2482.000 @ 20.000), (N/A, 20.00)
> >        (2474.000 - 2494.000 @ 20.000), (N/A, 20.00), NO-OFDM

> > Also, how
> > should the 2.4GHz part be interpreted?
> 
> Channels 1-11 allow 40 width channels, so HT40 is allowed.
> Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallowed.
> Channel 14 only allows OFDM.

s/OFDM/non-OFDM/

Ok, this is a bit of a problem. Let me break out of this thread and
propose new, slightly changed, interpretation rules.

> > Currently we are not interpreting overlapping ranges properly at all --
> > we really need to fix a set of interpretation rules.
> 
> Sort of, we currently stick to the first reg rule which fits our
> desired bandwidth. Right now we iterate through 2 possible max
> bandwidths -- 40 and 20 and then set the channel max bandwidth based
> on which one fits. Note though that we do disregard the freq_range max
> bandwidth, which my patches correct.

True. I'm rather keen on removing that code though -- it is rather
confusing to hardcode 20/40 in there and try them.

> We also need to consider for future usage custom bandwidths, which I
> guess why we had the first JP rule for 4 GHz (but yeah the second rule
> seem to imply what the first one intends on allowing). First step
> might be to say allow drivers to use monitor mode with 10 MHz
> bandwidth or 5 MHz bandwidth. That of course would also need further
> work other than regulatory.

Indeed. The question is how we want to capture this. So far I was always
thinking that we would capture this as an extra channel type -- like
HT40+, but going the other direction -- "10MHZ"/"5MHZ".

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Japan regulations

[Luis R. Rodriguez]

On Sun, Mar 22, 2009 at 1:28 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sat, 2009-03-21 at 12:46 -0700, Luis R. Rodriguez wrote:
>
>> > country JP:
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0(2402.000 - 2472.000 @ 40.000), (N/A, 2=
0.00)
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0(2457.000 - 2482.000 @ 20.000), (N/A, 2=
0.00)
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0(2474.000 - 2494.000 @ 20.000), (N/A, 2=
0.00), NO-OFDM
>
>> > Also, how
>> > should the 2.4GHz part be interpreted?
>>
>> Channels 1-11 allow 40 width channels, so HT40 is allowed.
>> Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallo=
wed.
>> Channel 14 only allows OFDM.
>
> s/OFDM/non-OFDM/
>
> Ok, this is a bit of a problem. Let me break out of this thread and
> propose new, slightly changed, interpretation rules.
>
>> > Currently we are not interpreting overlapping ranges properly at a=
ll --
>> > we really need to fix a set of interpretation rules.
>>
>> Sort of, we currently stick to the first reg rule which fits our
>> desired bandwidth. Right now we iterate through 2 possible max
>> bandwidths -- 40 and 20 and then set the channel max bandwidth based
>> on which one fits. Note though that we do disregard the freq_range m=
ax
>> bandwidth, which my patches correct.
>
> True. I'm rather keen on removing that code though -- it is rather
> confusing to hardcode 20/40 in there and try them.

Agreed, which is why I got rid of them in my patches too.

>> We also need to consider for future usage custom bandwidths, which I
>> guess why we had the first JP rule for 4 GHz (but yeah the second ru=
le
>> seem to imply what the first one intends on allowing). First step
>> might be to say allow drivers to use monitor mode with 10 MHz
>> bandwidth or 5 MHz bandwidth. That of course would also need further
>> work other than regulatory.
>
> Indeed. The question is how we want to capture this. So far I was alw=
ays
> thinking that we would capture this as an extra channel type -- like
> HT40+, but going the other direction -- "10MHZ"/"5MHZ".

That would work.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html