Handling maximum transmit power requirements by regulatory region

[sjlongland]

Hi all,

A few years back, we underwent the necessary steps to start selling a Thread-based product in the US market, which meant we were required to comply with the FCC rules regarding maximum transmit power on certain frequencies.

The device we ship has a +22dBm power amplifier. For the US market, we could run at a maximum of +20dBm power on most channels, but a couple we had to limit to +11dBm. This is a restriction we didn't have in the Australian market. (The EU was even more strict: +10dBm across the board.)

At the time, OpenThread added the otPlatRadioGetRegion and otPlatRadioSetRegion calls, but no drivers actually supported this feature. It was up to us to actually implement the power limiting feature.

My approach then was firstly to generate a look-up table and function that, given a region, a channel and a target TX power; could tell me the TX power to use, and then to modify the radio driver (CC2538 in our case) to clamp/update the transmit power when changing the radio TX power or channel:

/*!
 * Transmission prohibited.  Emissions regulations in this region prohibit
 * any transmissions taking place on this frequency at any power level.
 *
 * @see txp_get_max
 */
#define TXPTABLE_PROHIBITED (INT8_MIN)

/*!
 * Convert a region in ASCII to a region code.
 *
 * @param[in]	ascii_code	The region code represented as an ASCII
 * 				string, assumed to be at least 2 bytes long.
 *
 * @returns	The ISO-3166-2 code represented as an integer.
 */
static inline uint16_t txp_region_code_from_ascii(const char* ascii_code) {
	return ((((uint16_t)(ascii_code[0])) << 8)
		| ((uint16_t)(ascii_code[1])));
}

/*!
 * Convert a region code to ASCII.
 *
 * @param[in]	code		The region code as an integer.
 * @param[out]	ascii_code	The buffer where the region code will be
 * 				stored, assumed to be at least 2 bytes in
 * 				size.
 */
static inline void txp_region_code_to_ascii(uint16_t code, char* ascii_code) {
	ascii_code[0] = (char)(code >> 8);
	ascii_code[1] = (char)(code & 0xff);
}

/*!
 * Get the maximum transmit power level for the given region and channel.
 *
 * @param[in]	code		The region code to look up.
 * @param[in]	channel		The channel number to look up.
 *
 * @returns	The maximum transmit power level in dBm.
 * @retval	TXPTABLE_PROHIBITED	Transmission on this channel is
 * 					prohibited in this region.
 */
int8_t		     txp_get_max(uint16_t code, uint8_t channel);

/*!
 * Clamp the given transmit power to the maximum permitted power for the
 * region code and channel.
 *
 * @param[in]	code		The region code to look up.
 * @param[in]	channel		The channel number to look up.
 * @param[in]	power		The desired transmit power level in dBm.
 */
static inline int8_t txp_clamp_power(uint16_t code, uint8_t channel,
				     int8_t power) {
	int8_t max = txp_get_max(code, channel);

	if (power > max)
		return max;
	else
		return power;
}

We're porting the codebase across to the nRF Connect SDK and its version of OpenThread. I see looking at the APIs, otPlatRadioSetChannelTargetPower was recently added as an optional feature. For Thread certification purposes, we're using their binary build, which means modifying the driver to call our code is not possible.

Given this is a problem that affects all commercial users of OpenThread shipping products built on it (regardless of what hardware platform they use, many will use the library toolkits provided by their vendors), it would appear a common approach is what should be aimed for here, since the actual maximum transmit power we permit is going to be dependent on multiple factors:

• the region the device is operating in (configured via otPlatRadioSetRegion)
• the current channel the device is operating on (nominally via otPlatRadioSetChannel, but OpenThread also hops channels momentarily to "scan" for other nodes).
• the presence of power amplifiers added by the designer/manufacturer that influence the transmit power
• the design of radio antenna (EIRP requirements)

It's not possible for a chip designer or the OpenThread team to know the above. Thus we need a hook in OpenThread that allows us to clamp the transmit power specified to the radio driver. This hook would need to be called in the otPlatRadioTransmit function, as the radio frame encodes what channel we're on (mChannel) and the radio configuration sets the region and maximum power.

Question is, how do we go about adding such a hook to OpenThread?

Is this currently possible with the existing builds and I just missed something or is this something that needs to be implemented in the OpenThread core, and filter down through the vendor SDKs?

Are there vendors already handling this in their drivers? Which ones are not?

Thanks in advance.
Regards,

[LuDuda]

Hello @sjlongland,

Right, nRF Connect SDK does not implement optional Radio Platform APIs such as otPlatRadioSetRegion or otPlatRadioSetChannelTargetPower. We might consider implementing these, though I can imagine, that some product makers would like to implement them on their own.

For now, you can use the following function to achieve your use case: mpsl_tx_power_channel_map_set (https://github.com/nrfconnect/sdk-nrfxlib/blob/main/mpsl/include/mpsl_tx_power.h#L95C9-L95C38), while setting the maximum default TX power. This function takes into account FEM gain as well.

In your view, does OpenThread need a new API for this, or is it more a matter of SoC vendors providing broader implementations of the existing optional APIs?

By the way, it is also possible to use certified OpenThread libraries from NCS and still implement power mapping as part of the application or through radio port extensions.

[sjlongland]

Yep, well that definitely helps on Nordic Semiconductor platforms. Next time I'm looking at that code base (next year some time) I'll have a closer look.

I suppose my point being is this: this is a problem that will be common to all OpenThread implementers, so we really should have common APIs that can be portable to all platforms.

If a vendor say, picks up a Silicon Labs chip for a project (they've got a quite nice looking chip with a built-in +20dBm PA) and make a product with it, they'll need to implement this channel map for their product to comply with regional power limits.

Let's suppose that chip became unavailable to them for some reason (e.g. there was a chip shortage), and so temporarily, they prototype an alternative using a TI chip (who also have a decent offering with a +20dBm PA). Assuming the antenna doesn't change between the designs and no laws change, the only thing that's changed is the OpenThread HAL that implements the radio driver.

In that hypothetical situation, the product developer shouldn't have to re-write their power channel map code just because they've switched vendors. They should be able to feed in the same channel power map into the driver HAL, and it do the right thing on either chip.

Now, if that's achieved via vendors implementing the optional APIs, or by adding new APIs to the codebase, doesn't worry me… but I should be able to say, "Hey OpenThread, you're running in the US, channel 11-24 have a +22dBm limit but 25 and 26 have a +20dBm limit!"… or "Hey OpenThread, you're running in the EU, you must run no more than +11dBm on any channel!"

It shouldn't matter if it's a TI, SiliconLabs, Nordic Semiconductor or NXP part, the same restrictions apply. :-)