A new LWM2M Message Node

[pchainho]

As discussed with @aoncorici and reported in D5.1, the Hotel Guest scenario will require a LWM2M Message Node and its associated LWM2M Protostub.

[emmelmann-fokus]

Hi Paulo,

if I remember correctly from the recap I got about D5.1, our original contribution talked about a LWM2M Server which was then renamed based on your feedback into "LWM2M Message Node".

So my understanding is that the kid just got a new name but is still the same inside.

The implementation will be based on http://leshan.eclipse.org/#/clients from what I got. @aoncorici might possibly correct me / supplement more information.

[pchainho]

Yes, the kid inside can be the same but we need some appropriate "clothes" to make it compliant with reTHINK Msg Node. Not much should be needed and, probably, many components developed for other Message Nodes can be reused. It will also depend on the use cases to be supported.

At least, we need the LWM2M protostub ie a javascript that converts reTHINK Messages into LWM2M protocol. Since both are CRUD based operations, it should be straightforward. The Vertx protostub is a good reference implementation.

Then, we need a connector to the Domain Registry (where LWM2M domain related Hyperties are registered) and Address Allocation (where the LWM2M domain related Hyperties addresses are managed). Again, Vertx Address Allocation and its Registry Connector are a good starting point.

Another option is to put another Msg Node, like Vertx, in front of the LWM2M and then, probably, it is just a question of developing a connector (or protostub) between the Msg Node and LWM2M.

What do you think?

[aoncorici]

Hello Paulo,

I would go for the first option - direct link the LWM2M message node that receives LWM2M messages. What we can do, if necessary is to do a translation between reThink messages and LWM2M messages as a protostub. As in our usecase we plan to use from the device LWM2M protocol directly (still needs to be tested for HOP Ubiquous devices), we will have to see if there is another usecase, another partner that needs the protostub, otherwise we might implement it without benefit.

References: http://www.hopu.eu/ Still to be evaluated: ARM devices, we need to buy some: https://blog.benjamin-cabe.com/2015/07/08/remote-management-of-an-arm-mbed-device-using-lwm2m-wakaama-leshan

For the moment interfaces to Registry and Address Allocation are not needed yet/are not envisioned by the Hotel Application usecase.

What is already happening is interface towards the Identity Management System to get users authenticated and their role. This would be the main point: access control.

Do you know if role based access is supported by the Identity Management System or we have to implement it ourself.

[rjflp]

@pchainho The second option, using Vertx as an intermediate between LWM2M and everything else reThink would probably save lots of work. We are talking about communicating with the Domain Registry, IdPs (?), etc, which is already done in the Messaging node. Should we go about replicating all of this to LWM2M, effectively creating a parallel infrastructure? Would it not be simpler to create a LWM2M connector on the Message node? What would both paths imply in terms of development effort and future maintenance?

[aoncorici]

dear all,

we are talking about devices from vendors that talk LWM2M. if we have first version we have at most 1 adaptor, if other usecases are interested. If we pick the second option we have to develop 2 adaptors at least just to have our own usecase running (Southbound and Northbound). I think this was not even mention mention I adapted to the name Message Node. If this is missleading, we can go back to M2M server.

[rjflp]

@aoncorici Maybe I did not understand this correctly. Will this inter-operate with the rest of the Rethink architecture? Or is this independent? Do Hyperties play a part?

[pchainho]

Hi @aoncorici, @rjflp I think the question is, would this LWM2M device support reTHINK runtime ie a Javascript engine like NodeJS?

[rjflp]

Probably not. But a gateway could bridge these "non rethink devices" with ReThink. And this gateway would be ReThink "compliant".

[aoncorici]

reThink browser runtime will run on the mobile phone and workstation. This is where we specified the hyperties.

[pchainho]

What are the interactions needed between the Hyperties and the LWM2M server?

[aoncorici]

Pull information that was received from the sensors or even better, pull information after the data was analysed.

[aoncorici]

that is LWM2M/CoAP read operation

[pchainho]

no pub/sub?

collected data by these, let's call for now, LWM2M hyperties can be published to let other authorised hyperties consume it?

[aoncorici]

yes, of course, we could have hyperties doing processing near the server/message node. The only thing is: what would be the requirements for implementing this. I just need to evaluate if we can afford the effort :D.

[pchainho]

ok, now I think I see the big picture for your scenario and not much effort should be needed:

1- put a NodeJS Runtime in front of the LWM2M Server and no need to have any LWM2M protostub since I believe there is already some NodeJS LWM2M module

2- have a Context Producer Hyperty for each device or set of devices connected to LWM2M. These LWM2M Hyperties would directly interact with NodeJS LWM2M module APIs to collect data from the LWM2M. Then, some processing can be done and published to a certain Context URL via the Syncher component. This is something very similar to the Bracelet Hyperty

3- then your Hyperties in the Browser Runtime (smartphone or workstation) that have permissions to access the published data can consume it ie they are Context Consumer Hyperties.

At the end this would mean, the LWM2M would not be a Msg Node but an Hyperty Runtime Server.

What do you think?

[aoncorici]

1) Mhh...We would really like to use the Leshan server, Java implementation. It is quite mature and appreciate it in the community, we used it also for the catalogue. The hyperties to access the data can do that via CoAP or HTTP (it has a built-in translation to memory stored objects).

2) Can you please understand that the devices we will use are not under our control, but coming from a real manufacturer and we cannot put a context producer hiperty.

3) hiperties or applications on mobile device and workstation will access the service using the Leshan resources. The hyperties will be javascript.

Weekend is coming, will have to go now home. Can we have a call on Tuesday if this is not clear enough.

[pchainho]

I didn't explain well enough.

Nodejs Runtime would not replace the LWM2M server you want to use but encapsulate it to make it seen from reTHINK perspective as an Hyperty Server Runtime.

[pchainho]

@aoncorici , can we agree on this solution?

[aoncorici]

I will have to check with my colleagues how Javascript fits Java code and if it fits. Also my question would be: why does it have to be Javascript.

[pchainho]

you don't have to mix javascript and java. The NodeJS would interface the M2M Server with LWM2M itself. See picture:

Javascript was chosen at the very beginning because it is a scripting language supported in browsers and in most of the targeted platforms. In future we might support other languages in case there is support for that in the Hyperty Runtime. But I would say this is out of scope of the project taking into account the required effort.

[aoncorici]

Hello Paulo, thank you for the picture. That helps. We will have a colleague validating the architecture and then next week Marc is back from vacation and will also discuss with him.

Btw, which hyperties you envision to have on the nodeJs. I just feel there is something missing from the picture, like an adapter to LWM2M.

[pchainho]

Btw, which hyperties you envision to have on the nodeJs.

These would be Hyperties encapsulating LWM2M devices, something similar to the Bracelet Hyperty.

I just feel there is something missing from the picture, like an adapter to LWM2M.

We wold consider LWM2M as part of the native runtime by using existing Libs like eg this.

[pchainho]

Do we have a deal, regarding this issue?

[aoncorici]

Dear Paulo, still no decision yet. We would like to evaluate if we can use the NodeJs implementation directly. Will give you feedback next week, most probably.

[aoncorici]

What we did was to have the physical devices pointed to our Open5GMTC LWM2M server and now we have to see what extensions are needed, as the devices from HOPU transfer the sensor data as IPSO alliance Smart Objects, embracing the LWM2M model of smart objects, but tailored for sensors. ipso_smart_objects.zip

[aoncorici]

Dear Paulo,

We experimented with the nodejs LWM2M implementation (https://github.com/telefonicaid/lwm2m-node-lib) and we were able to link the physical sensors to the LWM2M server. Thus, we decided to use that server as lwm2m server. The nodejs library will be extended with a new nodejs module including: interface to Identity provider, real-world modelling capability, http(s) interface to communicate with the Admin and Hotel guest hyperties. The source code will be held here:https://github.com/reTHINK-project/scenario-service-implementation/tree/master/nodejs_rethink_module_lwm2m. Currently is in the phase of design (from whiteboard to written text :D )

[pchainho]

These are great news! However, the repo is the dev-runtime-nodejs and not the "scenario-service-implementation" repo.

Pls, align with @avallee-apizee and @vitormsilva about the tasks to be performed, but there should be no need to have integration done with identity provider or specific network interfaces with Hyperties. It should be just a question of choosing an appropriate sandbox implementation for nodejs like http://gf3.github.io/sandbox/ you have proposed sometime ago.

[emmelmann-fokus]

@aoncorici are there any updates. We discussed this issue in today's telco and were not sure if we can close this issue. If we don't have any updates, please close this issue.