[RFC] set radio_reg — Explicit regulatory framework selection for RF compliance

[jirogit]

Background

PR #2218 implemented Japan-specific LBT (Listen Before Talk) compliance for the 920 MHz band (ARIB STD-T108), using runtime frequency detection to activate Japan mode automatically. This works for the immediate use case, but raises a broader design question.

Problem

RF regulatory requirements vary by regulatory framework, not strictly by country:

• The same framework can span multiple countries (e.g., ETSI EN 300 220 covers EU + UK)
• The same country can have different requirements per frequency band (e.g. Malaysia: unrestricted at 919–923 MHz, 1% duty cycle at 923–924 MHz — see Add Malaysia LoRa presets #980)
• Automatic frequency-based detection is implicit and hard to extend

A dedicated setting would make compliance intent explicit and auditable.

Proposal

Add a radio_reg setting (regulatory domain) with the following initial values:

Value	Framework	Key constraints
ARIB	ARIB STD-T108 (Japan 920 MHz)	LBT −80 dBm, TX ≤4s, post-TX 50ms
ETSI	ETSI EN 300 220 (EU/UK)	10% duty cycle
FCC	FCC Part 15.247 (USA)	No LBT or duty cycle (DTS mode)
NONE	No enforcement	Default / experimental

Prior discussion

PR #2218 (Japan LBT implementation) — first raised set radio_law concept in review response
PR #1297 (token bucket duty cycle enforcement) — demonstrates community demand for proper ETSI duty cycle compliance; reviewer discussion confirms FCC/AU/NZ regions require no duty cycle enforcement
Issue #2079 (Japan LBT tracking issue)

Relationship to existing settings

• set region — controls repeater forwarding filter (unrelated)
• set radio_reg — controls RF regulatory compliance behavior

These two settings serve different purposes and should remain independent.

Notes

• Initial implementation could migrate PR Add Japan LoRa LBT compliance (ARIB STD-T108) with runtime frequency detection #2218's frequency-based auto-detection to explicit ARIB mode
• ETSI duty cycle enforcement would be a separate follow-on contribution. For FCC (DTS mode), no LBT or duty cycle enforcement is required by Part 15.247
• ARIB refers specifically to ARIB STD-T108 (920 MHz band). ARIB STD-T67 (400 MHz band) is out of scope for current hardware but the naming leaves room for future extension
• radio_reg targets compliance with the underlying radio law requirements (e.g. ARIB STD-T108), not device certification such as Japan's 技適 (Giteki). Users are responsible for operating within their regulatory framework
• 433 MHz amateur radio operation (e.g. Part 97 in USA, JARL band plan in Japan) is out of scope for this RFC. Amateur radio involves licensing and band plan requirements that differ fundamentally from ISM regulatory frameworks and would warrant a separate discussion
• Open to naming alternatives (phy_compliance, rf_reg, etc.)

[dl9sau]

In EU we have not 1 % airtime but 10%, on the used 869 main frequency.
Other freuencies the 869 band have 0,1 % airtime (what means 3-4 packets per hour).

An other good feature woud be:
Settings like mikrotik for wifi does. User configures regulatory region and antenna gain. txpwr is automaticaly computed to e(i)rp (erp forcsrd in the eu).

And really confusing is that MC does not know if a heltec v4 in his high power 1W version. User has to search for docu, to find the calculation table (22 dBm setting means 30 dBm - or so..). This makes it really complicated and uncertain for users who like to be legal.

See also: #2034

[jirogit]

Thanks for the EU context and the pointer to #2034.

On ETSI duty cycle: You're right that the relevant limit for MeshCore in the EU is 10% — EU MeshCore communities (e.g. Switzerland) are operating on 869.6 MHz, which falls in the 869.4–869.65 MHz sub-band where 10% applies. This is exactly the band MeshCore users actually use, so a ETSI implementation in radio_reg would need to enforce that limit at that frequency. The broader sub-band structure in EN 300 220-2 is more complex, but I could not find real-world MeshCore networks using the 0.1% bands in practice. Do we need to consider 0.1% also?

On EIRP auto-calculation: The MikroTik-style approach is actually a natural extension of radio_reg rather than a separate feature — once the framework is known, the correct antenna gain logic follows from it. The underlying logic differs per framework though: ETSI would compute TX power from available ERP headroom (TX power = ERP limit − antenna gain); FCC uses EIRP limits; and Japan (ARIB) would instead validate the antenna gain against a fixed ceiling (≤3 dBi for ≤20 mW devices), since Japanese regulation constrains transmitter output and antenna gain independently rather than as a combined EIRP limit. Worth a dedicated issue to work through the per-framework details.

On Heltec V4 output offset: That's a hardware-layer problem — the board definition should expose a corrected dBm scale to the user rather than requiring manual lookup. Probably best raised with the board maintainer or as a separate issue.

[jirogit]

Note on generalizability: KR920 (South Korea)

The JP LBT implementation in #2218 should generalize to Korea with parameter substitution only — no structural changes.

Korea's 920 MHz band rules permit either LBT-AFA or duty-cycle operation, and the LoRaWAN KR920-923 regional parameters adopted LBT.

Semtech's reference implementation (LoRaMac-node, RegionKR920.c) uses:
RSSI free-channel threshold: -65 dBm (JP: -80 dBm)
Carrier sense time: 6 ms (JP: 5 ms continuous)
Duty cycle: disabled when LBT is used (same structure as JP's 920.6–922.2 MHz zone)

Since #2218 already implements continuous RSSI sensing with a configurable threshold and duration, a KR mode would essentially be a frequency-detection branch (analogous to isAS923_1_JP()) plus these two constants.

Caveat: the values above come from the LoRaWAN spec and Semtech reference code, not from the Korean regulation text itself. Anyone implementing a KR mode should verify the threshold, sensing duration, and any per-transmission time limits against the primary Korean regulatory source before treating it as compliant.

I have no KR hardware or local community contact to test against yet— leaving this here as a pointer for anyone in Korea who wants to pick it up.