Add AS_920_923 Japanese plan

tooruuetani commented 3 years ago

Summary

Add Japanese specific plan for AS923. Using from 920.6MHz to 923.4MHz with LBT.

Changes

Currently AS920-923 with LBT is incorrect in Japan. Because the Japanese law ARIB-STD-T108 need that LBT scan time is below:

128usec or more for 922.4MHz-923.4MHz
5msec or more for 920.6MHz-922.2MHz.

So we would like to use AS920-923 with 5msec scan time. And also we would like to use three patterns as below:

920.6MHz-921.2MHz(4ch) and 922.8MHz-923.4MHz(4ch)
922.0MHz-923.4MHz(8ch)
920.6MHz-922.0MHz(8ch)

The last plan is for 16ch gateway, is only used with second plan.

about ARIB-STD-T108

The low power regulations is from page 33. The frequencies for 20mW or less are described from page 50.

see attached table1 and table2

Notes for Reviewers

We would like to use 128usec scan time for 922.4MHz or upper, but TTSC denies that frequency specific scan time. So we can't use 128usec scan time. (note) The Kerlink gateways allow frequency specific scan time.

Checklist

[x] Scope: The referenced issue is addressed, there are no unrelated changes.
[x] Compatibility: The changes are backwards compatible, they don't break existing deployments.
[x] Testing: The changes are tested.
[x] Documentation: Relevant documentation is added or updated.

tooruuetani commented 3 years ago

[Uploading 5-STD-T108v1_3-E1.pdf…]()

johanstokking commented 3 years ago

Thanks a lot @tooruuetani.

So you need to be able to configure per-sub-band (frequency) scan times? How does Kerlink gateways configure this?

And also we would like to use three patterns as below:

920.6MHz-921.2MHz(4ch) and 922.8MHz-923.4MHz(4ch)

922.0MHz-923.4MHz(8ch)

920.6MHz-922.0MHz(8ch)

Can you elaborate a bit on this? Is this specific to your use case?

tooruuetani commented 3 years ago

Yes, we need to be able to configure per-sub-band (frequency) scan times. For example, Kerlink iStation with cpf describes like below:

"lbt_cfg": {
    "enable": true,
    "rssi_target": -80,
    "chan_cfg": [
        { "freq_hz": 920600000, "scan_time_us": 5000 },
        { "freq_hz": 920800000, "scan_time_us": 5000 },
        { "freq_hz": 921000000, "scan_time_us": 5000 },
        { "freq_hz": 921200000, "scan_time_us": 5000 },
        { "freq_hz": 922800000, "scan_time_us": 128 },
        { "freq_hz": 923000000, "scan_time_us": 128 },
        { "freq_hz": 923200000, "scan_time_us": 128 },
        { "freq_hz": 923400000, "scan_time_us": 128 }
    ]
}

Can you elaborate a bit on this? Is this specific to your use case?

We think that this is not only our case. Because 920.6MHz-923.4MHz is used by a gateway which can transmit at 250mW or less. (note) Please see attached PDF page 7 "Land Mobile Station".

We need 1st pattern, because we already deployed the ABP devices using 1st pattern.
We need 2st and 3rd patterns, because we may use a gateway which has 16ch like Kerlink iBTS.

tooruuetani commented 3 years ago

Japanese frequency plans are separated by 4 plans. This PR is targeted for 920.6MHz-923.4MHz at 20mW. Please see Table3-18 and Table3-8. We mainly use these frequencies at 20mW or less, sometimes use at 250mW or less from a gateway.

920.6MHz-922.2MHz with 5msec LBT scan time, and also which can transmit at 250mW or less
922.4MHz-923.4MHz with 5msec LBT scan time, and also which can transmit at 250mW or less
922.4MHz-923.4MHz with 128usec LBT scan time, and also which can transmit at 250mW or less
922.4MHz-928.0MHz with 128usec LBT scan time

table3-8

(remarks) We made a request for 250mW, then issue #7 was re-opened.

tooruuetani commented 3 years ago

Sorry, I made a mistake. When using LBT 5msec scan time, dwell time limitation is unnecessary. So I removed some plans using dwell time.

johanstokking commented 3 years ago

OK, I need to keep this one open for now. We are working on some refactoring regarding (gateway) frequency plans, that also affects >8 channel plans and generating gateway configuration files (with, for example, LBT per sub-band).

@adriansmares please reference this issue in the umbrella

tooruuetani commented 3 years ago

@johanstokking I appreciate for comment.

Will you merge this PR for the time being? Because TTSC does not have correct frequency plans for Japan, we can't proceed the migration to TTSC.

johanstokking commented 3 years ago

@tooruuetani yes on the short term, we accept fixes for https://github.com/TheThingsNetwork/lorawan-frequency-plans/blob/f77e7cc095ca01d173bdae0b2f5d2277e69c7d53/frequency-plans.yml#L156-L162.

tooruuetani commented 3 years ago

Thanks. We will wait for merging.

tooruuetani commented 2 years ago

How is the progress ? Will this PR be merged by Q1?

johanstokking commented 2 years ago

@adriansmares do we have any blockers on our side?

adriansmares commented 2 years ago

This is no longer blocked by The Things Stack, but I do have some concerns about this PR:

Naming is not ideal - all of the plans are called Japan 920-923 MHz with LBT - how can we create a good separation ?
- We probably want to include the frequency ranges at least
- We probably want to mention they are TTN endorsed
IDs are not descriptive - I think that Standard/Separate/Optional don't say much
- Using _JP_TTN_1/_JP_TTN_2/_JP_TTN_3 is fine I think, since it ensure that this

These are permanent frequency plans - once they are released, gateways / end devices may use them forever and we cannot remove / rename them.

tooruuetani commented 2 years ago

@adriansmares Thank you. I agree with your naming concerns. But I don't have a good solution for this.

If I will choose your IDs idea, what should I do next ? (note) I will edit names and descriptions.

adriansmares commented 2 years ago

I think that after we clarify the IDs/names/descriptions this is good to be reviewed and merged.

tooruuetani commented 2 years ago

@johanstokking OK, I had an misunderstanding. I will modify band-id in the files.

tooruuetani commented 2 years ago

OK. I see.

TheThingsNetwork / lorawan-frequency-plans