subsys: net: lwm2m: Add LwM2M gateway object

[ahedin25]

Add support for the gateway object used by the MG100
BT510, and BT610 LwM2M demo.

Signed-off-by: Andrew Hedin andrew.hedin@lairdconnect.com

[carlescufi]

@ahedin25 do you want to take this out of draft and continue work on it?

[ahedin25]

Adding the RSSI to the gateway object was rejected by the OMA. I'll remove that change and take this out of draft.

[rlubos]

The object specification looks pretty neat, nothing really to complain about.

I'd appreciate however if you could shed some light on how could this LwM2M gateway be implemented. I understand that the data transfer between the gateway and end-device is out of the scope of this PR, since it's not defined by the spec and actually application-specifc, thus should by handled by the application.

It's not clear to me however how are the end-device objects represented on the gateway side. If I understand correctly, the Gateway device should create the appropriate object instances on behalf of the end-device, it seems however that this requires one additional path level (device prefix) which isn't supported by the LwM2M engine. How did you manage to make LwM2M Gateway functional w/o changes in the engine?

[rlubos]

Perhaps we could just incorporate this header content into .c file, since it's not used elsewhere? The header is not exposed to the application.

[ahedin25]

We used the values in our application, so maybe I am did something wrong.

For example, during runtime we set the prefix of a discovered sensor.

if (cfg->prefix != NULL) {
	snprintk(
		path, sizeof(path),
		STRINGIFY(LWM2M_OBJECT_GATEWAY_ID) "/%u/" STRINGIFY(
			LWM2M_GATEWAY_PREFIX_RID),
		cfg->instance);
	lwm2m_engine_set_string(path, cfg->prefix);
}

Is there a different way this should be done?

[rerickson1]

in our app

#include "lwm2m_resource_ids.h"
#include "lwm2m_obj_gateway.h"

work to include those values. Is that a mistake in the Zephyr build system?

[rlubos]

It seems to be possible due to this line:
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/lwm2m/CMakeLists.txt#L5
I think it's not correct though - any API intended to be public, and thus used by the application should be added to /include/ directory. This needs a little cleanup I believe, i. e. we could create a public header for resoruce IDs and move all declarations in there.

[ahedin25]

We need to add the prefix to the engine.

For our first test, we used object 25 to show what sensors were present and we created instances for the sensor data that we wanted to use (that was gathered from advertisements).

In the future, we may not create any of the end node object instances on the gateway (other than object 25). We are going to tunnel the data.

Thread or an IP based scheme seems like a natural choice, but we need to talk to sensors using BLE Long Range. I think that leads to a custom solution. That is why we asked about selecting between multiple LwM2M transports.

[rerickson1]

In the future, we may not create any of the end node object instances on the gateway (other than object 25). We are going to tunnel the data.

Thread or an IP based scheme seems like a natural choice, but we need to talk to sensors using BLE Long Range. I think that leads to a custom solution. That is why we asked about selecting between multiple LwM2M transports.

This plays directly into #41313

[rlubos]

A few more questions regarding the target solution, based on https://www.openmobilealliance.org/release/LwM2M_Gateway/V1_1-20210518-A/OMA-TS-LWM2M_Gateway-V1_1-20210518-A.pdf (apologies for my ignorance, the topic is pretty fresh for me).

In the future, we may not create any of the end node object instances on the gateway (other than object 25). We are going to tunnel the data.

Wouldn't that be contrary to the aforementioned spec? In chapter 6 it states:

As soon as the LwM2M Gateway discovers an IoT Device and has sufficient information, it SHOULD create an instance of
the LwM2M Gateway Object. The LwM2M Gateway SHOULD also create the Device Objects associated with the IoT
Device

My understanding is that if the Gateway device creates a Gateway object instance for the end-device, it should also create instances for the objects reported by the end-device.

Thread or an IP based scheme seems like a natural choice, but we need to talk to sensors using BLE Long Range. I think that leads to a custom solution. That is why we asked about selecting between multiple LwM2M transports.

Is my understanding correct that in this solution, the end-device would be a fully fledged LwM2M client? Does that mean that the gateway device would then need to act as both LwM2M client and LwM2M server (to which the end-device would register to)?

[ahedin25]

The end-device will be a fully fledged LwM2M client.

Since the 1.1 specification uses the word SHOULD, we plan to make the gateway a proxy/bridge and only create object 25 for each end-device.