Japan region and Certification

[dagerlandsson]

Hi,
we are planning to create a device that must be certified in Japan. I see that there exists three different Japan regions dependent on what channels to use. I have built and tested this tree variants with LCTT but all of them fails in quite many test cases. If I build a plain AS923-1 it passes in all tests.
In RP002 it only say that LBT must be enabled. This tree configurations also limits what DR to use and what channels are possible to use.
So my question, what shall I build to be able to certify the device for Japan?

[mluis1]

The AS923-1 plus LBT is indeed the right region to operate in Japan. However, this is not the end of the story.
The LoRa-Alliance created the AS923 region plans in order to cover as many countries as possible. But each individual covered country can add additional restrictions which need to be complied with (It is the law).
The Japanese authorities impose additional restrictions defined by the ARIB STD-T108 Ver1.4 document.
This document reduce the number of usable channels frequency as well as the maximum channel bandwidth that can be used.

This is the reason why when choosing one of the possible variants provided by this project the AS923_MIN_RF_FREQUENCY, AS923_MAX_RF_FREQUENCY, AS923_TX_MAX_DATARATE, AS923_RX_MAX_DATARATE and other parameters are changed from the AS923-1 defaults.

The LCTT certification tool is setup by default to certify the AS923-1 region using its default parameters.

Therefore in order to be able to certify a LoRaWAN end-device meant to operate in Japan one needs to tweak some of the LCTT test parameters.

The tests requiring an adaptation of their parameters are shown below. The changed parameters are the channels frequencies to be used.

BV_001 
    922.800
BV_006
    922.000
    922.000;922.200;922.400;922.600;922.800;923.000;923.000;922.800;922.600;922.400;922.200;922.000;923.200;923.400
    920.600;920.800;921.000;921.200;921.400;921.600;921.800;922.000;922.200;922.400;922.600;922.800;923.000;920.600 <- Last frequency here is a repeated one because Japan regulations only allow 15 channels instead of 16
BV_012_A
    922.800
BV_012_B
    923.200
    923.200
    922.800

The gateway parameters must be changed as well in order to align the frequencies with the ones expected by LCTT.
The sx1302_global_conf_1250_lctt_as923_jp_lbt.json.txt provides an example for a SX1302 based gateway.

After applying these changes and setting this project with CHANNEL_PLAN_GROUP_AS923_1_JP_CH24_CH38_LBT all LCTT tests pass except one (BV_015_A).

The reason why the BV_015_A test fails is because the end-device only supports DR_0 to DR_5 data rates. Optional data rates DR_6(SF7BW250) and DR_7(FSK) not being usable as the channels maximum bandwidth is 200 kHz (Japan regulations).
At some point the LCTT test sequence uses an Rx1DrOffset value which ends up being one of the end-device unsupported optional data rates. Therefore, the test fails as the end-device is unable to use the optional data rates.

I have reported this issue to the LoRa-Alliance certification committee in order to get this situation fixed.
While a solution is not found to solve the BV_015_A issue I think that it should be possible for the Authorized Test House to ask the LoRa-Alliance for a waiver and therefore obtain the final end-device certification.

[dagerlandsson]

Thanks for this detailed information. I can confirm what you say, with default configuration and correct channels in LCTT it will only fail on the mentioned test.

Have tested to let the device accept DR7 on RX, e.g. comment out the lines that correspond to AS923_RX_MAX_DATARATE to let it be the default DR7. When running like that all tests in LCTT is PASS.
Is there any drawbacks to run in this way? I guess that there is nothing in ARIB STD-T108 Ver1.4 that disallow the device to listen on DR7. Can you see any scenario that will make the device behave bad?

[mluis1]

I also did the same fix as the one you propose and you are right there is nothing wrong with it.

I did not mentioned this because your proposed fix works for this stack implementation. However, other stacks implementations may not support the optional data rates.
Therefore my goal was/is to get the certification tool fixed in order to correctly handle this situation.

Once the certification tool is fixed I will apply the proposed fix. As you mention the end-device is not required to limit its reception parameters. It is up to the transmitter to comply with the country national regulations.