Home » Eclipse Projects » OM2M » OM2M & oneM2M(Understanding the similarities and differences between these architectures.)
|
Re: OM2M & oneM2M [message #1691624 is a reply to message #1691396] |
Wed, 08 April 2015 14:27 |
Francois Aissaoui Messages: 38 Registered: April 2015 |
Member |
|
|
Hello David,
As you said, the ETSI M2M architecture and the oneM2M architecture share common concepts concerning resources, some communication protocols, etc. Unfortunately, there is no document that highlights the differences between them.
However, the OM2M team is currently working on the oneM2M documents to provide a new version of the platform that will implement the new standard.
But, the platform will not handle ETSI M2M and oneM2M at the same time, there will be two versions completely separated.
The last release, version 0.8.0, supports the ETSI M2M. This version is going to be updated among time with feature enhancement and bug fix but will keep the ETSI M2M compliance.
We are currently working on the new version, the 1.0.0, that will support the oneM2M standard but it will no longer support ETSI M2M. Even if the architectures have similarities, they are different (no more collection object for instance) and can not be integrated in a single platform.
In a nutshell, if you want the last version of OM2M with ETSI standard compatibility, you have to checkout the last 0.8.x version. The version 1.x.x and more will handle the oneM2M standard.
François
[Updated on: Thu, 16 April 2015 08:50] Report message to a moderator
|
|
| |
Re: OM2M & oneM2M [message #1691689 is a reply to message #1691672] |
Thu, 09 April 2015 05:22 |
David Antliff Messages: 10 Registered: April 2015 |
Junior Member |
|
|
While on the topic of oneM2M - does Mahdi's first example here where a resource URI is automatically retargeted to an existing HTTP application have some sort of equivalence in oneM2M? The only "retargeting" I could find in the oneM2M spec is related to Notification Retargeting. This makes use of an "Application Entity Point of Access", which sounds like it may be similar to an "Application Point of Contact", but it looks like they are not the same.
This automatic re-mapping of a resource to an external HTTP URI seems very useful - if oneM2M can support this, it makes it easier to interface a oneM2M system with existing services. If oneM2M does not support such automatic remapping, in what ways can an application provide a synchronous bridge between a CSE and an external HTTP service?
[Updated on: Thu, 09 April 2015 05:23] Report message to a moderator
|
|
|
Re: OM2M & oneM2M [message #1692501 is a reply to message #1691689] |
Thu, 16 April 2015 09:32 |
Mahdi Ben Alaya Messages: 229 Registered: November 2013 |
Senior Member |
|
|
Hello David,
We are not sure yet about all the features to be included in the next OneM2M release (OM2M 1.0.0). But our goal is to provide a full implementation of the standard step by step through several releases.
Regarding device management, support for the LightweightM2M protocol can be integrated in the OM2M 1.1.0 release. We will try to publish a detailed roadmap as soon as possible.
Open Daylight provides an open source implementation of SDN. In addition, it will include a mapping to interface with the OneM2M standard. As far as I know, this is the role of IoTDM, I did not heard about a full oneM2M implementation.
Actually, the OneM2M architecture is mainly discussed in the OneM2M mailing lists, web meetings, and face-to-face meeting which are accessible only for OneM2M members.
But, we can create a dedicated topic in our Eclipse Forum like this one to discuss in details the OneM2M architecture, interfaces, bindings, etc.
OneM2M supports re-targeting as the same way as ETSI SmartM2M.
- In MCC interface: re-targeting between CSEs using a "CSE Point of Access" (CSE-PoA)
- In MCA: re-targeting from CSE to AE using an "Application Entity Point of Access" (AE-PoA)
Mahdi
[Updated on: Mon, 20 April 2015 02:49] Report message to a moderator
|
|
| |
Re: OM2M & oneM2M [message #1692824 is a reply to message #1692818] |
Mon, 20 April 2015 03:25 |
Mahdi Ben Alaya Messages: 229 Registered: November 2013 |
Senior Member |
|
|
Hello David,
In OneM2M, notification retargeting is not necessary a result of subscription. It can be done simply by sending a NOTIFY request to an AE including an AE-PoA.
The notification representation is designed to be general. In fact, it contains a tag called "m2m:operation" that informs about the corresponding CRUD method.
I agree with you that this is not a good REST practice since the verb is stored inside the resource representation. Thus, I am sure I will keep direct CRUD retargeting in the OM2M implementation
By the way, to make your scenario working with native OneM2M, you have to use an interworking proxy that creates an AE resource in the local CSE by setting the interworking proxy id as AE-PoA.
Then, any NOTIFY request coming to the AE will be re-targeted to the interworking proxy. This notification is in reality implemented as a simple library call.
Now, the interworking proxy can read the "m2m:operation" tag from the received notification and so send the right CRUD request to the corresponding device.
[Updated on: Mon, 20 April 2015 03:31] Report message to a moderator
|
|
| |
Re: OM2M & oneM2M [message #1698585 is a reply to message #1697120] |
Tue, 16 June 2015 14:20 |
Mahdi Ben Alaya Messages: 229 Registered: November 2013 |
Senior Member |
|
|
Hello Fatima,
The main differences between the SmartM2M and OneM2M architectures are:
- OneM2M defined a new node called MN-CSE (Middle Node CSE) also called Transit-CSE for multi-hop communications. So, a more advanced routing mechanism is required here to re-target the request from a node to another.
- OneM2M introduced two new types of requests called "Non blocking Synchronous request" and "Non blocking Asynchronous request". The Non blocking mode is useful when the request execution time is long so an application can chose to retrieve the response later by sending a separate request (Non blocking Synchronous) or to simply be notified when the result is ready (Non blocking Asynchronous).
- A new interface called mcn is also defined to handle the communication between a CSE and an Underlying Network.
- MQTT communication binding is provided.
- LightweightM2M device management is supported as well.
- The "collection" resource is removed from oneM2M. The main idea here was to reduce the size of the URI. Personally I am not happy with this alternative. I believe that "collection" is a pattern for RESTful architecture. Without collections the migration becomes difficult and implies an important change in all resource structures. That's why we decided to develop OneM2M as a new project.
Have a good day
[Updated on: Tue, 16 June 2015 14:21] Report message to a moderator
|
|
| |
Re: OM2M & oneM2M [message #1713360 is a reply to message #1711249] |
Tue, 03 November 2015 14:52 |
Francois Aissaoui Messages: 38 Registered: April 2015 |
Member |
|
|
Hello Vijayalakshmi,
Sorry for the late reply.
Right at the moment we do not have document that compare the two standards but we are planning to provide a quick migration guide from the version 0.8 to 1.0 of OM2M after the 1.0 release.
Regards,
François
|
|
|
Goto Forum:
Current Time: Fri Apr 26 01:19:52 GMT 2024
Powered by FUDForum. Page generated in 0.04701 seconds
|