Add support of LWM2M Gateway (Object 25) at Server Side.

[sbernard31]

Following discussion at #1237 (comment), we start to work about Gateway support in Leshan v2.x.

Here is the specification : LwM2M_Gateway-v1.1.1.

A LwM2M Gateway allows a LwM2M Server to manage end IoT devices "behind" the LwM2M Gateway. The protocols
used between the LwM2M Gateway and its connected end IoT devices and any protocol translation carried out by the
LwM2M Gateway are outside the scope of this specification.

This issue aims to discuss/specify modification needed to add Gateway support at Server side.

Registration

Code design

We could add new kind of registration : GatewayRegistration, EndDeviceRegistration.
I don't know yet if we should go with :

• Change Registration to make it an interface.
• Create a DeviceRegistration concrete class (which replace former Registration one)
• Add GatewayRegistration, EndDeviceRegistration classes

OR

• Add GatewayRegistration, EndDeviceRegistration classes which inherit from current Registration one

I have not full design in mind yet but at least :

• GatewayRegistration will contain a new attribute : list of child end device endpoint name
• EndDeviceRegistration will contain new attributes : its prefix and the registraiton id of the parent gateway.

Maybe we should also create dedicated LwM2mIdentity class for end device ? Maybe this is even enough and you don't need class above ☝️ ? 🤔 This is maybe more true for end device where we can eventually consider prefix+registrationId parent gateway as part of identity but for Gateway hard to consider the `list of children" as part of identity...

behavior

On gateway registration, in registration payload we know if there is instances of Gateway (obj 25)
If yes we can read object 25 and create a new registration for each instance.

On gateway registration update, we can detect if there is new end device (register) OR if some are removed (deregister)

On gateway deregistration, we need to deregister/remove all child device (ideally in an atomic manner)

How to handle end device ? Maybe it's up to the Gateway to use send operation to notify that IoT Device Objects (resource 3) changed...

Device Management And Service Enablement and Information Reporting Interfaces

Simple Operation

The "Read", "Discover", "Write", "Write-Attributes", "Execute", "Create", "Delete", and "Observe" should works out of the box 🤔

Composite and Send Operation

The "Read-Composite", "Write-Composite", and "Observe-Composite" operations can target the Device Objects by
prepending the name of the targeted Object, Object Instance, Resource, or Resource Instance with the Prefix associated
to an IoT Device

Resources and Resource Instances values from the Device Objects can be part of the reported values

If we don't support that composite and send operation support several end devices at same time there is not too much modification. But the specification allow it and users will probably need it.

For Read-Composite and Observe-Composite request, we need to list path from different device...
So should we modify LwM2mPath to add a possible device prefix ?

For all those operations we need to decode/encode payload from different devices, so from different object models.
That means we need to change API to not only provide a model but a kind of ModelProvider which is able to provide model by prefix.

[AbdIssa98]

For handling in code, I find it more reasonable to have the GateWayRegistration and the EndDeviceRegistration classes with the mentioned attributes, while also having a new LwM2MIdentity for child devices in a way that would make the changes I did to the registration store in 1723 not needed. In my current implementation getting the registration by address will return the child/endDevice since it uses the same IP address as the gateway device and that gets over written in the store then.

[sbernard31]

I start to code some idea about API in gateway_server branch.

I meanly try to find how to support Composite and Send Operation which is the most impacting feature from a design point of view.

So I added support of PrefixedLwM2mPath to TimestampedLwM2mNodes
So decoders/encoders will be able to handle several prefixed data in same payload.

I also added Add a way to get child model by prefix to LwM2mModel, so decoders/encoders will be able to access to right model to decode/encode.

Next step, I consider to add children to registration (for gateway) but don't know yet If I should change create Interface with new Class hierarchy OR if I just add new code in Registration (which is maybe already too big ..)

[sbernard31]

I have work in progress about Registration class hierarchy design.
(Changes to look at are mainly in org.eclipse.leshan.server.registration package)
As expected this is impacting code... I'm pretty sure I will add a EndDeviceRegistration kind of registration.. but maybe for gateway this will just be adding some attribute to current Registration...

[AbdIssa98]

@sbernard31 Hi,
are there any new updates on this? is there a timeline for when this might be available for use?

thank you in advance :)

[sbernard31]

@AbdIssa98, I'm working on it.
But this takes much time as expected 🙃:

1. Not so easy to integrate this feature with current Leshan design/API : I'm not really satisfy by all ideas I tried until now ...
2. I was slowed down a bit by the previous version release (I had to manage some process changes).

About timeline, hard to say but this is one of my top priority task on Leshan. (At least the server side one)

On your side do you have any timeline to share ?
Could you eventually provide some helps (If yes, which kind ? 🙏 maybe code review, changes feedbacks, tests ?)

[AbdIssa98]

@sbernard31
On our side there is no tight timeline, but it would be most beneficial if we could have that within the first half of 2026.

I can provide code review, and test any changes that need testing on the matter, and provide feedback on it.

[sbernard31]

In gateway_server branch, I have a first POC (but still doesn't support Send and Composite Operation)

I added a crappy hardcoded hack in leshan client to be able to test that with LeshanClientDemo.
Because of that tests doesn't pass.
So to build that branch : mvn clean install -DskipTests.

Then you can run leshan server demo with :

java -jar leshan-demo-server/target/leshan-demo-server-2.0.0-SNAPSHOT-jar-with-dependencies.jar

And client demo with :

java -jar leshan-demo-client/target/leshan-demo-client-2.0.0-SNAPSHOT-jar-with-dependencies.jar -fb '"/25/0/0"="enddevice","/25/0/1"="d01","/25/0/2"="</3>;ver=1.2,</3/0>"'

My interesting code are in InMemoryRegistrationStore and the new Registration class hierarchy...
But I see several issue with this design :

• this put a lot of logic in the registration store. (but I don't know how to do differently and be able to keep atomic modifications)
• I do not so much how to handle child registration modification / events... (current way is not so good)

[sbernard31]

@AbdIssa98 , Oh question in your Gateway use case what is the end device lifecycle ?

I mean this seems more or less mandatory for me 👇 :
I mean the gateway register to the server.
I guess the server will automatically do a read on object 25 to extract end device registration.
Then the gateway will periodically do some register update.

But in your case does End devices could had object or object instance dynamically ?
If yes that means that resource 3 of corresponding object will changes.
How server is aware about that in your case ?
Client use Send Operation ?
server observe object 25 ? (I do not like some much observe feature)
or server do some polling ?

[jvermillard]

I guess the server will automatically do a read on object 25 to extract end device registration.

As far as I recall, you also need to read the object25 on registration update in case the content changed and the "endpoint" device changed their structure. This is a bit overkill because I imagine the endpoint devices to be BLE tags or something alike with limited logic and so limited risk of being dynamic. But I seen devices like that which where advertised over object 25 but not fully initialised and the LWM2 object were coming "online" in a second time. So I think it would be safer to allow the user to decide: read /25 only at registration, or also on update.

BTW since I'm commenting here, if some company would like to speed-up this implementation, I'm always available to be hired for this kind of jig

[sbernard31]

The branch should not contain a first try for a working Send Support for gateway.
Now I explore Read Composite request.